| 1 |
Ühel kenal päeval, R, 27.01.2017 kell 23:58, kirjutas Kent Fredric: |
| 2 |
> On Fri, 27 Jan 2017 09:32:23 +0100 |
| 3 |
> Fabian Groffen <grobian@g.o> wrote: |
| 4 |
> |
| 5 |
> > I'm interested to hear how other people feel about this. |
| 6 |
> |
| 7 |
> Yeah. Pretty much my reaction to |
| 8 |
> |
| 9 |
> Mart Raudsepp <leio@g.o> wrote: |
| 10 |
> |
| 11 |
> > The maintainer should be giving the choice of both, |
| 12 |
> > but if only one can be chosen, the maintainer should make the |
| 13 |
> > choice |
| 14 |
> > for you by preferring one of them. Likely gdbm, given berkdb |
| 15 |
> > licensing |
| 16 |
> > saga. |
| 17 |
> |
| 18 |
> Brought the same question to me: |
| 19 |
> |
| 20 |
> If the design is intended to force your hand when you have both, what |
| 21 |
> is indeed |
| 22 |
> the point of a REQUIRED_USE feature at all? |
| 23 |
|
| 24 |
It can be very useful in some cases, especially when these cases |
| 25 |
involve local USE flags in a way that the errors come after enabling |
| 26 |
something locally in an unsuitable way. |
| 27 |
But yes, ideally the package manager would have a clue about what |
| 28 |
happened for the cases like the one in question, but REQUIRED_USE |
| 29 |
provided a faster solution to some of the problems that could be |
| 30 |
implemented in package managers in a reasonable time for the EAPI this |
| 31 |
was introduced in. |
| 32 |
We could work on top of this in a future EAPI. |
| 33 |
|
| 34 |
> If "choose a useflag for the user" is something that is happening, it |
| 35 |
> should |
| 36 |
> at least be *visible* to the user that this is happening, not being a |
| 37 |
> silent |
| 38 |
> decision that didn't allow the user to have any say in the matter. |
| 39 |
> |
| 40 |
> What if the feature you chose instead, was contrary to the one they |
| 41 |
> wanted? |
| 42 |
> |
| 43 |
> If anything, I think this is a suggestion that *maybe* we should a |
| 44 |
> way to |
| 45 |
> specify a mechanism for allowing a default to be chosen from a |
| 46 |
> mutually |
| 47 |
> exclusive set, and then: |
| 48 |
|
| 49 |
Sure, I have some thoughts for this and a rough draft, at least in my |
| 50 |
head :) |
| 51 |
I don't have it as a priority to sketch it out well alone, but if |
| 52 |
someone is honestly interested, I could braindump my ideas in realtime |
| 53 |
medium. Or someone thinks of them themselves :) |
| 54 |
|
| 55 |
> a. Inform the user via pretend output that this automatic conflict |
| 56 |
> reduction |
| 57 |
> has been performed |
| 58 |
> |
| 59 |
> b. Define a portage option that disables automatic conflict |
| 60 |
> resolution for |
| 61 |
> required USE, so users who hate (a) can turn it off. |
| 62 |
> |
| 63 |
> |
| 64 |
> But as it stands, Mart's suggestion of "Hey, just don't use required |
| 65 |
> use, |
| 66 |
> decide for the user" stands essentially as a regression against |
| 67 |
> portage itself. |
Archives