Gentoo Archives: gentoo-alt

From: Zac Medico <zmedico@g.o>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] RFC: changing sys-apps/portage python API to use $EROOT instead of $ROOT for keys to portage.db and similar map objects
Date: Sat, 01 Oct 2011 21:56:58
Message-Id: 4E878C9D.4020901@gentoo.org
In Reply to: Re: [gentoo-alt] RFC: changing sys-apps/portage python API to use $EROOT instead of $ROOT for keys to portage.db and similar map objects by Fabian Groffen
On 10/01/2011 11:27 AM, Fabian Groffen wrote:
> Hi Zac, > > On 01-10-2011 10:34:02 -0700, Zac Medico wrote: >> As I integrate prefix support into mainline portage, I think it will > > Cool! and Thanks! > >> make more sense to use $EROOT instead of $ROOT for keys to portage.db >> and similar map objects. This will also affect the portageq commands >> which take a <root> parameter. The reason that I think $EROOT makes more >> sense for these keys is that it will allow for multiple prefixes to >> exist simultaneously in maps like portage.db. >> >> This won't affect non-prefix users, since $EROOT == $ROOT when $EPREFIX >> is empty. So, I'm asking here because if might affect prefix users who >> use portageq, or any programs installed in a prefix that use the >> sys-apps/portage python API. If necessary, I suppose that python >> programs could have some compatibility code which checks whether or no >> $EROOT is contained in portage.db, and fall back to "/" otherwise. > > What does it actually mean? Does one have to use > portageq envvar CHOST $EPREFIX/ > instead when this is implemented? > That would seem not correct to me.
Well, it wouldn't apply to portageq's envvar command, since that doesn't have a <root> argument. These are the portageq commands that would be affected: all_best_visible <root> best_version <root> <category/package> best_visible <root> [pkgtype] <atom> contents <root> <category/package> expand_virtual <root> <atom> filter_protected <root> get_repo_path <root> <repo_id>+ get_repos <root> has_version <root> <category/package> is_protected <root> <filename> list_preserved_libs <root> mass_best_version <root> [<category/package>]+ mass_best_visible <root> [<category/package>]+ match <root> <atom> metadata <root> <pkgtype> <category/package> [<key>]+ owners <root> [<filename>]+ -- Thanks, Zac