On 06/03/2016 07:35 AM, Ian Stakenvicius wrote: > On 02/06/16 09:48 PM, Nick Vinson wrote: >> On 06/02/2016 08:08 AM, Raymond Jennings wrote: >>> use case: Telling a package to build a gui without deciding which one >>> to build. Also helps in cases where you have package A that can only >>> build a qt gui, and package B that can build both qt and gtk, and >>> package C that can build gtk only. You want to have a gui for all >>> three, but you don't want to hav epackage B build both guis and at the >>> same time while you may prefer qt, you don't want to leave package C >>> without a gui. >> >> How do you decide which one package B builds in such a case? >> >> Honestly, I don't think this is a good idea. The rationale and >> suggested implementation just don't bring enough benefit in my opinion. >> Often times it's hard enough to research a reported issue with the >> current implementation. Having a flag like 'gui' whose behavior >> (potentially) changes based on what profile is being used makes things >> considerably harder. It would no longer be a simple matter of matching >> versions and USE flags, the package maintainer would also need to setup >> an equivalent system with the same profile or research what the 'gui' >> flag with profile 'x' does and setup an equivalent USE flag set. > > > OK this makes absolutely no sense. > > USE=gui is about building the graphical user interface that an > application offers, when it is optional. That's it. What > dependencies that means and so on have nothing to do with the flag.
Which only works with packages that provide support for a single GUI implementation. 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). 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. > It's the same as USE="server" to build the server daemon for an app > that provides both client and server. Maybe if IPX was still popular and I had to be concerned about whether "server" would favor a TCP/IP server or an IPX one, but that's not the case, so I don't see the two being equivalent here. In fact, I see this flag more like the 'dedicated' USE flag (which in my opinion, causes more problems than it solves). > > You get that use flags are not supposed to represent dependencies > right, but features of the package?? If you're only able to debug a > build of your package because the flag is called gtk instead of gui, > well... I'm well aware how use flags are supposed to work, thank you. Also had you actually read what I had wrote and the context surrounding it, you probably wouldn't have made such an asinine remark. > > >> >> Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly >> do the same thing. The only thing they don't do (as I understand the >> profiles) is enable GUI support for packages that don't support the >> preferred libraries. Is that really enough justification to implement >> this flag? > > Yes. > > More specifically, the cleanup of all of those other uses of flags > that are there just to trigger a gui build instead of to indicate a > choice between options, is also enough justification. Think about a > wayland system -- there's lots of packages that IUSE="X" to build > their gui implementation. If someone wanting wayland set USE="-X" > then they don't get the gui app even if it'll work in wayland just fine. > > Yes, the USE=gui on this hypothetical app may well pull in Xorg libs, > but that's not a reason to keep the flag called "X", because again, > its about the feature of the package *not* the dependency. Sure it is. The feature is supporting X11 not Wayland or some hypothetical "omnigui". Do you really think upstream is going to care if their X11 app fails to work correct correctly in Wayland, but runs fine in a native X11 setup? I tunnel X11 over ssh all the time, do you really think it makes more since for me to have to set the 'gui' flag to do this instead of the X flag? Yes, I agree that the 'X' flag should control a feature. For most packages, that feature is integrating with an X11 environment (i.e. providing X11 bindings) and for most packages the X11 feature introduces dependencies on the X11 libraries. The gui flag won't change that. Nor does it make sense to rename 'X' to gui just because a Wayland user misconfigured his system. In your scenario, the user requested that the packages not be built with the X feature, so that's what they got. The fact that it would have otherwise worked with Wayland is immaterial. > > >> >> As a maintainer I'd ask that, at the very least, a more compelling >> reason than "it's too annoying to update package.use" is given. I find >> the argument against putting all the flags in global a valid but weak as >> there are already mitigations for that scenario. Perhaps I'm missing >> something, but I'm not convinced this will provide a significant enough >> benefit to the average Gentoo user to offset the increased >> troubleshooting demand it'll put on Gentoo's developers, maintainers, >> and proxy-maintainers. > > > Again, you will very much need to elaborate on what these increased > troubleshooting demands are. If anything, I see this flag, which will > allow the various tooklit flags to just mean a choice between > toolkits, to make things *easier* for troubleshooting, not harder. 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. > > >
signature.asc
Description: OpenPGP digital signature
