| 1 |
On 03/06/16 11:26 PM, Nick Vinson wrote: |
| 2 |
> |
| 3 |
> [ Snip! ] In cases where there's more than 1 option, you have to |
| 4 |
> either introduce RESTRICTED_USE as Patrick alluded to, or decide a |
| 5 |
> pecking order (or decide who gets to decide the pecking order). |
| 6 |
|
| 7 |
|
| 8 |
Which dev's already need to do, without USE=gui -- this is not a |
| 9 |
deviation from the status quo. |
| 10 |
|
| 11 |
|
| 12 |
> |
| 13 |
> and in that case, it *does* matter what dependencies the gui flag will |
| 14 |
> pull in. Even if the user doesn't care, there's no reason for it to |
| 15 |
> pull in version A when version B is also supported by the package and |
| 16 |
> every other package with GUI support is using version B. |
| 17 |
> |
| 18 |
|
| 19 |
And USE=gui is not going to eliminate said choices when there are |
| 20 |
choices between toolkits for a package. |
| 21 |
|
| 22 |
> |
| 23 |
> Some of the proposals on how to handle the case where a package supports |
| 24 |
> more than 1 implementation (e.g. supports qt and gtk), lead me to think |
| 25 |
> that the gui flag would inadvertently mask how a package was actually |
| 26 |
> built and configured. In such a case, troubleshooting is potentially harder. |
| 27 |
> |
| 28 |
> If that can't (or won't) happen, you can disregard that paragraph. |
| 29 |
|
| 30 |
|
| 31 |
That can't or won't happen. NOTHING about the USE=gui proposal turns |
| 32 |
deterministic things into automagic things. It's just about |
| 33 |
restructuring the determinism. |
| 34 |
|
| 35 |
Now, as is the case already for packages like this without a |
| 36 |
REQUIRED_USE line, if a package supports just one of both gtk and qt5, |
| 37 |
and both flags are enabled, then the package maintainer needs to |
| 38 |
determine which one takes precedence and the state of the other will |
| 39 |
be ignored. This isn't ideal since it can amount to useless rebuilds, |
| 40 |
but it isn't automagic either. |
Archives