-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kristian Benoit wrote: > 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 >
In either kind of list editing of this type would have to be allowed. However black/whitelists are still necessary IMHO. You don't know what vars destroy builds, but the maintainer does. Why wouldn't you want him blocking out a variable that is KNOWN to break a build? Modifying the API to print things blacklisted would be easy and if the maintainer has blacklisted something important for you you can always remove it via some setting ( /etc/portage or otherwise ). Alec Warner (antarus) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQwqaq2zglR5RwbyYAQKz+g//TQTaZCV+oXw/R6tLzSQhe0qhZcxDfSMz Kdy8q6FHsXxwJ4QSVudszQnvmLBKVlSXXGHMFAmbOHq/ATyesnFG+bGjRPHxiPfV ZW+PDRNJ/1LvInMVa6LyhjrSyKVz3XlqPIfCNoo9AdWM8s38lonG8zapsolkLs2b sA5v40xQVCA1PhvYMdCOeNdfK2PJSqh9wLj8NTdSJOqffZWBpLGd50TFgLVSXbhd u5hCoXK/kivWJ9pYCBgKwffEC78OOHSjmhkslxQR5luVJcn5ijs8P2fQUbPM5YGS 2BfGDRthj0lNTlo2Jt4QhnjkdQTPXMzRAbhLuVWsYYJl6+1ngMgWkM2jKV9P1WuE gilDrAuU83pl4vRX2Gh5jtYlzDScRQqe/vwzKaXXjEjQNfwCUmhh82tDgGSDmSo7 bMLrDGA6xj7ptqMLDOqewpwVvqCR2FQ9Qq/ZgQidmnjNcX83wd1cJZBKyszP5KIG YMztpKAb9TsGgdfHo0yV694vVoTlpBQ9B2wv+47FJReSw0bCWvUbqIsuAOGcGJzk 8HczKv/ySWc20pm6muBLrC63HAcGa0siE1ZQLTmyCLfN7G6yeFrK4Si9e5qQzF05 QVQCXLORq84v2cLJgiEkhysYEMFDSYkYBPZJ831eWuab/yrXAdT7IvoEPDmnRsM2 0ocP3wXhSGA= =t2n9 -----END PGP SIGNATURE----- -- [email protected] mailing list
