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