Bug 309369 – declare usage in env Portage dumps breaks Pkgcore/Paludis

• Product: Gentoo Hosted Projects
• Status: RESOLVED FIXED

[Description David Leverton 2010-03-14 13:09:42 UTC]

Portage currently creates environment.bz2 files that use the bash declare command to set each variable's value, export status, etc.  The problem is that when declare is executed inside a bash function it automatically becomes "local".  This breaks Paludis and Pkgcore because both source environment dumps for uninstalls/pkg_info/pkg_config/binpkgs within functions, so the variables don't get preserved when running the phases.  It could potentially be a problem in future if the Portage team wants to move their env sourcing into a function too.

We probably want to do one or more of:
* Change Portage not to use declare
* Add a workaround to Pkgcore and Paludis
* Specify what the env file can and can't contain, either in PMS itself or a separate VDB spec (that hopefully all package managers would support just as much as PMS)

[Comment 1 David Leverton 2010-03-14 14:15:00 UTC]

(In reply to comment #0)
> * Add a workaround to Pkgcore and Paludis

Paludis in git now copes with this.

Thanks to ferringb for noticing and reporting this problem, BTW.

[Comment 2 Zac Medico 2010-03-14 21:49:56 UTC]

The declare changes were done in order fix a probem with saving/loading arrays (bug #297255). Maybe we can find some alternative approach, or transform the declare output so that it's less troublesome.

[Comment 3 Brian Harring (RETIRED) 2010-03-15 00:02:40 UTC]

just released pkgcore 0.5.11 working around it.  Nasty alias trick, but it suffices.

Additional note, as of pkgcore 0.5.11, it's dumping data the same way as portage- basically that cat's out of the bag, so I went that route since portage tries to rely on filtering on declare via an external script.

[Comment 4 David Leverton 2010-03-15 18:20:41 UTC]

Turns out this also affects ebuilds that use declare in global scope.  Do we want to allow that?  (It probably won't work in eclasses even with Portage.)

[Comment 5 Brian Harring (RETIRED) 2010-03-15 22:55:06 UTC]

(In reply to comment #4)
> Turns out this also affects ebuilds that use declare in global scope.  Do we
> want to allow that?  (It probably won't work in eclasses even with Portage.)

I'd say declare is pretty much offlimits considering those issues- I sure as shit will not be inlining the env setup and sourcing of ebuilds into my main funcs to support it.

Portage *probably* can get away with it since it's ebuild.sh isn't a library, but at some point I'd expect it to become one- then it's in the same boat as pkgcore/paludis.

[Comment 6 Brian Harring (RETIRED) 2012-10-18 06:35:15 UTC]

added a workaround for pkgcore a long time ago.

If paludis can't handle it... well, 1) this is why environment saving should've been documented (despite certain folk screaming), 2) it's been long enough, portage/pkgcore aren't going to reverse away from declare- thus paludis needs to update their implementation if they haven't yet.