| 1 |
On Sat, Sep 16, 2006 at 11:02:06PM +0100, Ciaran McCreesh wrote: |
| 2 |
> On Sat, 16 Sep 2006 00:17:21 -0700 Brian Harring <ferringb@×××××.com> |
| 3 |
> wrote: |
| 4 |
> | On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote: |
| 5 |
> | > Protected locations are determined by the ``CONFIG_PROTECT`` |
| 6 |
> | > environment variable, which is defined in the profiles and which |
| 7 |
> | > may be augmented or overridden by the current environment and user |
| 8 |
> | > configuration files. |
| 9 |
> | |
| 10 |
> | The user env override has no relevance to ebuilds relying on it, thus |
| 11 |
> | doesn't have any business being mandated imo (it's implementation |
| 12 |
> | choice, not requirement of ebuilds). |
| 13 |
> |
| 14 |
> Hrm, so installing env.d files that set CONFIG_PROTECT isn't reliable? |
| 15 |
|
| 16 |
Suspect you missed my point- |
| 17 |
|
| 18 |
"Overriden by the current environment", aka the users environment |
| 19 |
at the time of executing $PKG_MANAGER). |
| 20 |
|
| 21 |
To build configurationm, portage stacks a bunch of mappings- the last |
| 22 |
one is the environment the script was ran in. In other words, |
| 23 |
|
| 24 |
CONFIG_PROTECT='' emerge blah # does disable CONFIG_PROTECT |
| 25 |
|
| 26 |
Portage allows CONFIG_PROTECT from the user env to override; that |
| 27 |
doesn't mean it's required for CONFIG_PROTECT support, which was the |
| 28 |
point. |
| 29 |
~harring |
Archives