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>^>>>[\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>^>>> Waiting 5 seconds</notinfo-1>
<notinfo-2>^>>> \([Cc]ontrol-[Cc] to abort</notinfo-2>
<notinfo-3>^>>> [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>^>>> 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
next prev parent 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