From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E7Pen-00041S-53 for garchives@archives.gentoo.org; Tue, 23 Aug 2005 03:41:01 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7N3ddSx000139; Tue, 23 Aug 2005 03:39:39 GMT Received: from egr.msu.edu (jeeves.egr.msu.edu [35.9.37.127]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7N3dc4K014585 for ; Tue, 23 Aug 2005 03:39:39 GMT Received: from [207.72.143.170] (207-72-143-170.dovers_res_net.spartan-net.net [207.72.143.170] (may be forged)) (authenticated bits=0) by egr.msu.edu (8.13.4/8.13.4) with ESMTP id j7N3eQ1b027576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Aug 2005 23:40:26 -0400 (EDT) Message-ID: <430A9AAB.2000709@egr.msu.edu> Date: Mon, 22 Aug 2005 23:40:27 -0400 From: Alec Warner User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050806) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] Environment Whitelisting References: <4308E349.8010107@egr.msu.edu> <20050822233323.276ad887@andy.genone.homeip.net> <20050822214059.GU10816@nightcrawler> <200508230828.10810.jstubbs@gentoo.org> <1124765166.6502.132.camel@localhost> In-Reply-To: <1124765166.6502.132.camel@localhost> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: f947f063-8434-415b-bce9-12fc5636541f X-Archives-Hash: 4a0371caa9e1aaec582cb5e60f1002fd -----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----- -- gentoo-portage-dev@gentoo.org mailing list