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