| 1 |
On Tue, 25 Sep 2012 18:20:06 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
> Who is we? I believe REQUIRED_USE is one of the features which will be |
| 4 |
> available thanks to staying compatible with USE flags instead of |
| 5 |
> reinventing the wheel. |
| 6 |
|
| 7 |
Yes, but the REQUIRED_USE wheel is square, and gives a *very* bumpy |
| 8 |
ride to users. It also isn't particularly easy for developers. |
| 9 |
|
| 10 |
> > b) How is consistency checking to be done? Related, what happens |
| 11 |
> > when a runtime switch introduces a dependency that then requires a |
| 12 |
> > non-runtime rebuild of the original package? |
| 13 |
> |
| 14 |
> Then the package is rebuilt. Where's the problem? |
| 15 |
|
| 16 |
The problem is in implementing that correctly... It's certainly doable, |
| 17 |
but it's not entirely trivial, depending upon how you're doing |
| 18 |
resolution. |
| 19 |
|
| 20 |
> Handling of |
| 21 |
> REQUIRED_USE is not perfectly user friendly but it works. |
| 22 |
|
| 23 |
Like a square wheel, yes. |
| 24 |
|
| 25 |
> > c) How do we deal with flag? ( cat/dep[foo] ) or flag? |
| 26 |
> > ( >=cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is |
| 27 |
> > installed and flag is off? From experience, quite a few places |
| 28 |
> > where you'd want to use suggestions will break if their suggested |
| 29 |
> > package is installed but doesn't meet version or use requirements. |
| 30 |
> |
| 31 |
> Er, you mean how to deal with an optional dependency which is not |
| 32 |
> enabled at all? |
| 33 |
|
| 34 |
I mean the *entire* thing I wrote. |
| 35 |
|
| 36 |
-- |
| 37 |
Ciaran McCreesh |
Archives