| 1 |
On Wed, 17 Apr 2013 14:58:20 -0400 |
| 2 |
Michael Mol <mikemol@×××××.com> wrote: |
| 3 |
> On 4/17/2013 2:48 PM, Ciaran McCreesh wrote: |
| 4 |
> > On Wed, 17 Apr 2013 14:33:29 -0400 |
| 5 |
> > Mike Frysinger <vapier@g.o> wrote: |
| 6 |
> >> but i'm super lazy, so even this manual step is annoying. as such, |
| 7 |
> >> i've added USE=multislot support to autoconf (just like it is with |
| 8 |
> >> binutils & gcc). |
| 9 |
> > |
| 10 |
> > But it's massively illegal and doesn't work correctly in Portage. |
| 11 |
> > |
| 12 |
> |
| 13 |
> For the benefit of those of us (well, me) not sufficiently versed in |
| 14 |
> PMS et al to be able to immediately deduce why it's illegal and why it |
| 15 |
> wouldn't work correctly in Portage, could you please elucidate? |
| 16 |
|
| 17 |
Metadata variables, such as SLOT, are cached and are required to be |
| 18 |
invariant. When an ebuild violates that requirement, the package |
| 19 |
mangler usually sees the wrong value for the variable when doing the |
| 20 |
resolution. This means the package mangler could calculate and display |
| 21 |
an invalid resolution for what it ends up doing, or it could ignore the |
| 22 |
ebuild's attempts at changing SLOT from what the cache holds, or it |
| 23 |
could do something even worse. |
| 24 |
|
| 25 |
-- |
| 26 |
Ciaran McCreesh |
Archives