| 1 |
On 2020-06-30 12:22, Matthew Thode wrote: |
| 2 |
> |
| 3 |
> I'd like to suggest allowing only approved variables in the build |
| 4 |
> environment, having portage unset all variables and setting only what is |
| 5 |
> needed (or configured). |
| 6 |
|
| 7 |
I think this is orthogonal to the problem I'm trying to solve. Even if |
| 8 |
all environment variables had to be whitelisted, ebuilds would still |
| 9 |
need to know how to use them when they happen to be defined. |
| 10 |
|
| 11 |
I basically just want to write down things like "If set, CC is assumed |
| 12 |
to contain the name of a compiler driver such as /usr/bin/gcc." That way |
| 13 |
ebuilds can be written to pass $CC to the build system in places that |
| 14 |
are expecting a compiler driver. Conversely, if LD is documented to |
| 15 |
contain a dynamic linker such as /bin/ld, then ebuilds must mangle LD |
| 16 |
whenever the upstream build system (e.g. pari, perl) interprets it |
| 17 |
otherwise. |
| 18 |
|
| 19 |
These meanings are already enshrined in the tc-getFOO() functions and |
| 20 |
the various de-facto standards, but there's no user or developer |
| 21 |
documentation promising that the variables will be used in any |
| 22 |
particular way. |
Archives