| 1 |
warnera6 wrote: |
| 2 |
>>> My preference would go 4, 3, 2 then 1. While Makefiles and configure |
| 3 |
>>> scripts may be "broken" upstream, how long is it before the breakage |
| 4 |
>>> goes unnoticed? More importantly, what's the chances of a dev finding |
| 5 |
>>> the breakage before users? Cleansing the environment to me is akin to |
| 6 |
>>> using sandbox. It offers protection against misbehaving packages... |
| 7 |
>>> |
| 8 |
>> |
| 9 |
>> Good point. How about if we add environment sandboxing support (in |
| 10 |
>> addition to filesystem sandboxing) to sandbox. With an environment |
| 11 |
>> sandbox, we could detect specifically which variables a build is |
| 12 |
>> fragile with regard to. The sandbox would have both filesystem access |
| 13 |
>> and environment access violation summaries. |
| 14 |
> |
| 15 |
> "environmental sandbox" being similar to sandbox, or the cleansing of |
| 16 |
> the environment? The latter is easy, the former...I am not sure how you |
| 17 |
> begin to detect variable use in bash :/ |
| 18 |
> |
| 19 |
|
| 20 |
AFAIK we can intercept getenv() calls the same way that we intercept filesystem calls. IMO the white/black/override lists would best be implemented at this level. |
| 21 |
|
| 22 |
Zac |
| 23 |
-- |
| 24 |
gentoo-portage-dev@g.o mailing list |
Archives