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. It's the same as USE="server" to build the server daemon for an app that provides both client and server. 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... > > 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. > > 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.
signature.asc
Description: OpenPGP digital signature
