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@...>
|
