1 |
On Tuesday 23 August 2005 08:56, Brian Harring wrote: |
2 |
> On Tue, Aug 23, 2005 at 08:28:08AM +0900, Jason Stubbs wrote: |
3 |
> > On Tuesday 23 August 2005 06:40, Brian Harring wrote: |
4 |
> > > On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote: |
5 |
> > > > Theoretical discussions about this are pointless IMO without |
6 |
> > > > numbers/facts to back things up. |
7 |
> > > |
8 |
> > > I'd posit theroetical discussions about this are pointless without |
9 |
> > > getting ebuild dev's to give a yay/nay on whether they want it or |
10 |
> > > not; not much for trying to force it down their throats if they don't |
11 |
> > > want it (more work, essentially). |
12 |
> > |
13 |
> > I don't really see what it has to do with ebuild devs... We're talking |
14 |
> > about the user's environment leaking into the portage build |
15 |
> > environment, no? Environment vars used by ebuilds can/should be set by |
16 |
> > users in a portage configuration file rather than being added to the |
17 |
> > environment. The only issue i see here is user customizations - fex, a |
18 |
> > hypothetical colorgcc that gets its config info from the env. |
19 |
> |
20 |
> Ixnaying user env leaking in will lead to bugs where ebuilds *allow* |
21 |
> for that, along with pissed off ebuild devs if they've not been made |
22 |
> aware of it oncoming. |
23 |
> |
24 |
> Hell, they may not even agree on the deterministic bit re: env; this |
25 |
> would explicitly block developers from fooling with autotool vars |
26 |
> (WANT_AUTOMAKE fex) for testing without mangling the ebuild. |
27 |
> |
28 |
> So yeah, I'm trying to ensure we're not screamed at for deploying what |
29 |
> (imo) is a good change, but may piss people off if it's not stated up |
30 |
> front (akin to glep 33). |
31 |
|
32 |
I think possibly our terminology is getting confused though.. Let's label |
33 |
stuff. I'll call the "build environment" (BE) that which an ebuild executes |
34 |
in, and the "calling environment" (CE) that which emerge (or whatever tool) |
35 |
was ran from. |
36 |
|
37 |
I see your point about the CE getting passed down to the BE for dev |
38 |
purposes. However, I don't see why stuff in the CE should be passed down to |
39 |
the BE in general. Aren't we trying to move away from users configuring |
40 |
stuff in the CE? How's about leaving the CE out of variable cascading |
41 |
altogether by default and just make it an option feature? :) |
42 |
|
43 |
With regards to white/blacklisting, I don't mind so much either way if the |
44 |
CE is not passed by default. However, I think that all portage-specific |
45 |
variables (such as FEATURES or PORTDIR) should not get passed down unless |
46 |
they really should be. I guess that sounds like blacklisting. |
47 |
|
48 |
-- |
49 |
Jason Stubbs |