From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23004 invoked from network); 18 Oct 2004 13:51:33 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 18 Oct 2004 13:51:33 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CJXvB-0002tC-MH for arch-gentoo-portage-dev@lists.gentoo.org; Mon, 18 Oct 2004 13:51:33 +0000 Received: (qmail 26133 invoked by uid 89); 18 Oct 2004 13:51:32 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 4226 invoked from network); 18 Oct 2004 13:51:32 +0000 From: Jason Stubbs To: gentoo-portage-dev@lists.gentoo.org Date: Mon, 18 Oct 2004 22:53:44 +0900 User-Agent: KMail/1.7 References: <200410172001.37303.jstubbs@gentoo.org> <1098030320.8046.19.camel@localhost> In-Reply-To: <1098030320.8046.19.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410182253.44450.jstubbs@gentoo.org> Subject: Re: [gentoo-portage-dev] Portage API X-Archives-Salt: be76af7b-3e8e-41f1-89c2-5d1d613faf70 X-Archives-Hash: 08411a75b9f6b28f1935db4452998d00 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