Re: [gentoo-portage-dev] Portage API

[Jason Stubbs <jstubbs@gentoo.org>]

On Monday 18 October 2004 01:25, Brian wrote:
> Dan has been the porthole developer that has done the most integrating
> portage modules for porthole's use, but it looks like we are loosing him
> from gentoo for now.

Yeah, I saw that..

> I have not had much reason to think about how much more we might need from 
> portage. 

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

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

> portage.auxdbkeys

I'm not sure what's required here either.

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

> portage.portdb.aux_get(ebuild, [property])[0]

Querying individual packages.

> portage.best(versions)

Package version comparison.

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

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

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.

Regards,
Jason Stubbs

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