| 1 |
On Sun, 2005-03-13 at 10:04 -0600, Brian Harring wrote: |
| 2 |
> On Sun, Mar 13, 2005 at 03:48:03PM +0000, Ciaran McCreesh wrote: |
| 3 |
> > On Sun, 13 Mar 2005 09:40:16 -0600 Brian Harring <ferringb@g.o> |
| 4 |
> > wrote: |
| 5 |
> > | Assuming no one can come up with a valid reason why the entire user |
| 6 |
> > | env must be dumped into the compilation environment, whitelisting of |
| 7 |
> > | vars that are allowed in would be the next step. LINGUAS, |
| 8 |
> > | EXTRA_ECONF, etc. |
| 9 |
> > |
| 10 |
> > Will this whitelist be developer-controllable, or will we have to wait |
| 11 |
> > several years any time we want something added to it? |
| 12 |
|
| 13 |
> At the moment, was thinking of having it be a stackable list, defaults supplied by portage, *potentially* profiles |
| 14 |
> can override/adjust it, and ebuilds themselves can request vars be brought in- note that's only possible *after* |
| 15 |
> sourcing the ebuild. Shouldn't be an issue anyways, cause people don't do evil things like env based |
| 16 |
> settings/adjustments in the global scope, right? :) |
| 17 |
|
| 18 |
So it will be something like $PORTDIR/profiles/env.accept.list in which |
| 19 |
all devs should be able to add to as needed vs having to file bugs and |
| 20 |
wait for long periods of time? |
| 21 |
|
| 22 |
> Re: portage controlling things, not the intention. Wouldn't be trying to move bin/* code into the tree if it were. |
| 23 |
> ~harring |
| 24 |
-- |
| 25 |
Ned Ludd <solar@g.o> |
| 26 |
|
| 27 |
-- |
| 28 |
gentoo-dev@g.o mailing list |
Archives