public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Brian <dol-sen@telus.net>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] Portage API
Date: Mon, 18 Oct 2004 09:14:39 -0700	[thread overview]
Message-ID: <1098116079.27883.70.camel@localhost> (raw)
In-Reply-To: <200410182253.44450.jstubbs@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 5492 bytes --]

On Mon, 2004-10-18 at 22:53 +0900, Jason Stubbs wrote:

> I'm more interested in what you are already using and more importantly why. 
> Whatever the API ends up being, it'll probably resemble portage's current API 
> very little.
> 
> I'll try to ascertain the why's from the what's that you've listed. Let me 
> know if I get any wrong.
> 
> > portage.grabfile():: used for obtaining [keywords.desc, use.desc,
> > use.local.desc]
> 
> Descriptions of USE flags. (I don't know what keywords.desc is.)
> 

keywords.desc does not exist on my system: func() call =
portage.grabfile('/usr/portage/profiles/keywords.desc')

It seems to be a depricated function in porthole, the output it stored
if found was not used anywhere.   I am deleting it.

> > portage.config(clone=portage.settings).environ()[var] :: where var = 1 of
> > ['PORTDIR_OVERLAY','PORTDIR', "USE"]
> 
> The current USE settings. I'm don't see why PORTDIR or PORTDIR_OVERLAY is 
> needed.

Porthole searches the directories for ebuilds, etc..  Better to use the
correct directories, so get the correct directories.  I believe Dan was
using portage rather than creating new code to scan thru /etc/make.conf
as well as the globals & defaults.

> 
> > portage.auxdbkeys
> 
> I'm not sure what's required here either.

I'll look into it further.


> 
> > """Extract installed versions from full name."""
> > return portage.db['/']['vartree'].dep_match(full_name)
> 
> Querying the installed package database.
> 
> > portage.db['/']['porttree'].getallnodes()
> 
> Querying the ebuild package database.
> 
> > portage.db['/']['vartree'].getallnodes()
> 
> As above.
> 
> > portage.catpkgsplit(ebuild)
> 
> Not sure why this is needed.

looks like = convienence, why re-invent the code to split the
cat/package-version.
 
> 
> > portage.portdb.aux_get(ebuild, [property])[0]
> 
> Querying individual packages.
> 
> > portage.best(versions)

for finding picking specific ebuild properties to display, etc.


> 
> > # showing complete porthole function for (possibly) more clarity
> > def get_properties(ebuild):
> >     """Get all ebuild variables in one chunk."""
> >     return Properties(dict(zip(keys,
> >                                portage.portdb.aux_get(ebuild,
> >                                                       portage.auxdbkeys))))
> >
> >
> > def get_versions(self, include_masked = True):
> >         """Returns all versions of the available ebuild"""
> >         # Note: this slow, especially when include_masked is false
> >         criterion = include_masked and 'match-all' or 'match-visible'
> >         return portage.portdb.xmatch(criterion, self.full_name)
> 
> I think these are both covered above.
> 
> > Wish list:
> >
> > Portages version comparison/handling code from bug:
> > http://bugs.gentoo.org/show_bug.cgi?id=37406 was would be implemented soon.
> >  I see browsing thru 2.0.51_rc9 that it is not yet implemented. If it is
> > being implemented Porthole should use the following from portage's code:
> >
> > ver_regexp =
> > re.compile("^(cvs-)?(\\d+)((\\.\\d+)*)([a-zA-Z]?)((_(pre|p|beta|alpha|rc)\\
> >d*)*)(-r(\\d+))?$") suffix_regexp =
> > re.compile("^(alpha|beta|rc|pre|p)(\\d*)$")
> > # modified portage comparison suffix values for sorting in desired
> > precedence suffix_value = {"alpha": '0', "beta": '1', "pre": '2', "rc":
> > '3', "p": '4'}
> 
> This is covered above with version comparison.
> 

No it isn't.   Portage's vercmp() is used to return the best ebuild of
two supplied.   Porthole needs to sort a list of available ebuilds to
proper order.  I based that code from Marius's changed code for vercmp()
so that porthole could display the ebuild version list in the correct
order.


> > That would allow porthole's modified version of that code to follow any
> > changes in portage's values.
> 
> I strongly recommend against doing any of this sort of stuff manually. I know 
> that there isn't really much choice at the moment, but that's exactly what 
> we're trying to get away from.

To use portage's vercmp() I would have to write a python bubble sort to
sort a list of ebuild versions.   What I did was use Marius's code and
modified it to pad the version string parts to 3 digits then used
python's builtin list.sort().

> 
> I believe porthole also makes a lot of use of emerge. If possible, please let 
> me know what options it is called with and what output is parsed.
> 
Porthole can currently send any emerge option by use of the advanced
emerge dialog for the most common advanced options or the run_custom
dialog which inputs any command to send to the terminal.  I have run ls,
python-updater and a few others as a test.

Due to porthole-terminal not being interactive commands such as "emerge
-a" will hang waiting for input that it can not receive.


We currently filter out any warning, caution, summary info including any
">>>" statements, einfo statements, errors.   For a complete list look
in the configuration.xml file attached.

I would like to change the terminal to use the vte gtk terminal widget
which could allow it to be a full function terminal with the message
filtering, su & chroot ability.  I did have a somewhat functional
version I tested but the python interface was incomplete and is not
really developed.  I would need to re-code the terminal in c. In case
you didn't know vte is gnome-terminals major workings that was split
into the main virtual terminal widget and the gnome-terminal
enhancements.


-- 
Brian <dol-sen@telus.net>

[-- Attachment #2: configuration.xml --]
[-- Type: text/xml, Size: 2329 bytes --]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<portholeconfig ver="0.3">
  <re_filters>
    <info py_type="list" item_count="5">
      <info-1>^&gt;&gt;&gt;[\s][^/]</info-1>
      <info-2>^\s\*\s</info-2>
      <info-3>.*[Rr]emember\sto</info-3>
      <info-4>.*[Ff]orget\sto</info-4>
      <info-5>^\!\!\!</info-5>
    </info>
    <notinfo py_type="list" item_count="6">
      <notinfo-1>^&gt;&gt;&gt; Waiting 5 seconds</notinfo-1>
      <notinfo-2>^&gt;&gt;&gt; \([Cc]ontrol-[Cc] to abort</notinfo-2>
      <notinfo-3>^&gt;&gt;&gt; [Uu]nmerging in:</notinfo-3>
      <notinfo-4>^\s\*\s[Cc]aching service dependencies</notinfo-4>
      <notinfo-5>.*libtool.*remember to run.*libtool</notinfo-5>
      <notinfo-6>.*libtool.*has not been installed in</notinfo-6>
    </notinfo>
    <warning py_type="list" item_count="4">
      <warning-1>.*[Ww][Aa][Rr][Nn][Ii][Nn][Gg][:\!,\s]</warning-1>
      <warning-2>.*[Ff]ile.*not found</warning-2>
      <warning-3>.*\s[Ee][Rr][Rr][Oo][Rr][:\-\!,]\s</warning-3>
      <warning-4>.*([Ss]yntax[Ee]rror|[Ss]yntax [Ee]rror[:\-\!,])</warning-4>
    </warning>
    <notwarning py_type="list" item_count="7">
      <notwarning-1>.*[Ii]f you wanted to set the \-\-build type</notwarning-1>
      <notwarning-2>.*(checking|check).* compiler warning flags</notwarning-2>
      <notwarning-3>.*(checking|check).* warning flags.* compiler</notwarning-3>
      <notwarning-4>.*remember to run.*libtool</notwarning-4>
      <notwarning-5>.*warning: \-jN forced in submake:</notwarning-5>
      <notwarning-6>.*has not been installed in `/usr/lib</notwarning-6>
      <notwarning-7>^libtool\:.*seems to be moved</notwarning-7>
    </notwarning>
    <error py_type="list" item_count="3">
      <error-1>^\!\!\!\sERROR\:.*\sfailed\.</error-1>
      <error-2>^\!\!\!\s[Ee]rror calculating dependencies.*[Pp]lease correct</error-2>
      <error-3>^\!\!\!\s[Ee]rror\:.*\sconflicts with another package</error-3>
    </error>
    <noterror py_type="list" item_count="0">
    </noterror>
    <caution py_type="list" item_count="1">
      <caution-1>.*[Cc][Aa][Uu][Tt][Ii][Oo][Nn][:!,\s]</caution-1>
    </caution>
    <notcaution py_type="list" item_count="0">
    </notcaution>
    <emerge>^&gt;&gt;&gt; emerge [^/]</emerge>
    <ebuild>^\d+\s+\[ebuild.*</ebuild>
  </re_filters>
</portholeconfig>


[-- Attachment #3: Type: text/plain, Size: 45 bytes --]

--
gentoo-portage-dev@gentoo.org mailing list

  reply	other threads:[~2004-10-18 16:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-17 11:01 [gentoo-portage-dev] Portage API Jason Stubbs
2004-10-17 16:25 ` Brian
2004-10-18 13:53   ` Jason Stubbs
2004-10-18 16:14     ` Brian [this message]
2004-10-19  1:08     ` Brian
2004-10-23 14:29       ` Jason Stubbs
2004-10-18 18:52   ` Daniel Taylor
2004-10-19 22:56     ` Daniel Taylor
2004-10-20  1:28       ` Brian
2004-10-18 20:08 ` Brian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1098116079.27883.70.camel@localhost \
    --to=dol-sen@telus.net \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox