On Tue, 2005-08-23 at 08:28 +0900, Jason Stubbs wrote: > On Tuesday 23 August 2005 06:40, Brian Harring wrote: > > On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote: > > > Theoretical discussions about this are pointless IMO without > > > numbers/facts to back things up. > > > > I'd posit theroetical discussions about this are pointless without > > getting ebuild dev's to give a yay/nay on whether they want it or not; > > not much for trying to force it down their throats if they don't want > > it (more work, essentially). > > I don't really see what it has to do with ebuild devs... We're talking about > the user's environment leaking into the portage build environment, no? > Environment vars used by ebuilds can/should be set by users in a portage > configuration file rather than being added to the environment. The only > issue i see here is user customizations - fex, a hypothetical colorgcc that > gets its config info from the env.
That's exactly what I was saying, we filter the environment to let only portage's variables (USE, FEATURE, ...) pass through. But the user may specify a bunch variables that will pass through. Ex: $ FOO=bar USE=X emerge vim vim's ebuild wont see the variable FOO but will see USE. But if someone run: $ PORTAGE_USER_VARS="FOO" FOO=bar USE=X emerge vim The ebuild will see both FOO and USE. But suppose that foo has 10 depencies and I want FOO to be defined only for vim. I can write /etc/portage/package.env.d/app-editors/vim: BAR=$TMP/bar FOO=$BAR/foo PORTAGE_USER_VARS="$PORTAGE_USER_VARS FOO" Then if I run: $ TMP=/home/me USE=X emerge vim The ebuild will see both USE and FOO but not BAR and TMP. It could also be only one file (/etc/portage/package.env): app-editors/vim "FOO BAR" app-... then FOO and BAR will be defined when running the ebuild if defined in the env. Or: app-editors/vim 'FOO=bar BAR="bla bla"' Which one do you prefer ? I think this give more freedom to the user than white/blacklisting and provide clean environment to the ebuilds. Plus no need for the package managers to manage white/blacklist. Kristian -- [email protected] mailing list
