Re: [gentoo-portage-dev] Environment Whitelisting

[Jason Stubbs <jstubbs@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

On Tuesday 23 August 2005 08:56, Brian Harring wrote:
> On Tue, Aug 23, 2005 at 08:28:08AM +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.
>
> Ixnaying user env leaking in will lead to bugs where ebuilds *allow*
> for that, along with pissed off ebuild devs if they've not been made
> aware of it oncoming.
>
> Hell, they may not even agree on the deterministic bit re: env; this
> would explicitly block developers from fooling with autotool vars
> (WANT_AUTOMAKE fex) for testing without mangling the ebuild.
>
> So yeah, I'm trying to ensure we're not screamed at for deploying what
> (imo) is a good change, but may piss people off if it's not stated up
> front (akin to glep 33).

I think possibly our terminology is getting confused though.. Let's label 
stuff. I'll call the "build environment" (BE) that which an ebuild executes 
in, and the "calling environment" (CE) that which emerge (or whatever tool) 
was ran from.

I see your point about the CE getting passed down to the BE for dev 
purposes. However, I don't see why stuff in the CE should be passed down to 
the BE in general. Aren't we trying to move away from users configuring 
stuff in the CE? How's about leaving the CE out of variable cascading 
altogether by default and just make it an option feature? :)

With regards to white/blacklisting, I don't mind so much either way if the 
CE is not passed by default. However, I think that all portage-specific 
variables (such as FEATURES or PORTDIR) should not get passed down unless 
they really should be. I guess that sounds like blacklisting.

-- 
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]