1 |
On Wed, Jul 1, 2020 at 9:36 AM Michael Orlitzky <mjo@g.o> wrote: |
2 |
> |
3 |
> On 2020-06-30 12:22, Matthew Thode wrote: |
4 |
> > |
5 |
> > I'd like to suggest allowing only approved variables in the build |
6 |
> > environment, having portage unset all variables and setting only what is |
7 |
> > needed (or configured). |
8 |
> |
9 |
> I think this is orthogonal to the problem I'm trying to solve. Even if |
10 |
> all environment variables had to be whitelisted, ebuilds would still |
11 |
> need to know how to use them when they happen to be defined. |
12 |
> |
13 |
|
14 |
Agree. I'm not actually certain what that proposal was intended to |
15 |
convey. Are we talking about: |
16 |
|
17 |
1. Blocking anything that happens to be in the environment when |
18 |
emerge is run? (Ie 'CFLAGS="-O2" emerge -1 foo'?) |
19 |
2. Blocking any variable at all that isn't whitelisted by an ebuild |
20 |
or eclass? (ie CFLAGS in make.conf is ignored unless the ebuild |
21 |
whitelists it) |
22 |
|
23 |
I get how environment pollution can cause issues, but #1 is something |
24 |
we've generally supported for a long time, and it is useful for |
25 |
troubleshooting/etc or just trying out different things. Maybe a |
26 |
FEATURE flag could be used to control it to keep newbs out of trouble, |
27 |
and you can just as easily pass that in the environment too. |
28 |
|
29 |
I'm not sure that #2 adds a lot of value. The default phase functions |
30 |
probably already don't work well for exotic build systems, and |
31 |
eclasses can of course take care of remapping for most of the popular |
32 |
ones. For one-offs some flag-o-matic or other eclass functions to aid |
33 |
in remapping variables might be helpful in some cases if there isn't |
34 |
already something there. |
35 |
|
36 |
But in any case it isn't essential to what you're proposing. It does |
37 |
go along with it to a degree and is worth at least thinking about |
38 |
(imo)... |
39 |
|
40 |
-- |
41 |
Rich |