| 1 |
On wto, 2017-05-30 at 04:30 +1200, Kent Fredric wrote: |
| 2 |
> On Mon, 29 May 2017 17:33:13 +0200 |
| 3 |
> Michał Górny <mgorny@g.o> wrote: |
| 4 |
> |
| 5 |
> > Automatically solving USE constraints solve all three fore-mentioned |
| 6 |
> > issues with REQUIRED_USE. By default, no user intervention is required |
| 7 |
> > to solve USE constraints and package.use needs to be modified only to |
| 8 |
> > enforce a non-standard solutons |
| 9 |
> |
| 10 |
> Overall I like the proposal, but one question: How do you envisage |
| 11 |
> automatic use-constraints interacting with --newuse? |
| 12 |
> |
| 13 |
> I have this feeling that "automatically enabled" flags could somehow |
| 14 |
> have an ephemeral nature, where a flag would be enabled at build time, |
| 15 |
> and then later a subsequent change in the graph toggles the flag off, |
| 16 |
> creating a potentially undesirable rebuild. |
| 17 |
> |
| 18 |
> I feel I might be imagining a problem because I might have a wire |
| 19 |
> crossed somewhere, so some sort of confirmation that I'm the insane one |
| 20 |
> and this can't happen would be reassuring :) |
| 21 |
|
| 22 |
I might be missing something but I don't think there would be any |
| 23 |
problems that we don't have right now. To the contrary, this proposal |
| 24 |
specifically reduces the amount of USE flag changes possible as flags |
| 25 |
can be more strongly bound to valid sets only. |
| 26 |
|
| 27 |
That said, the code running --newuse/--changed-use would probably need |
| 28 |
to account for the constraints, i.e. include them in calculating |
| 29 |
the effective set of USE flags. However, it's not much different from |
| 30 |
handling use.force/use.mask, and all the metadata is in place, so it |
| 31 |
shouldn't impact performance noticeably. |
| 32 |
|
| 33 |
-- |
| 34 |
Best regards, |
| 35 |
Michał Górny |
Archives