Dnia 2 czerwca 2016 21:36:10 CEST, waltd...@waltdnes.org napisał(a): >On Thu, Jun 02, 2016 at 06:50:59AM +0100, Graham Murray wrote >> waltd...@waltdnes.org writes: >> >> > Let me re-phrase my question... is there *ANY* set of >circumstances >> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE >flag >> > can be set for a package *WITHOUT* requiring a gui? >> >> Yes. X/xorg could be needed to incorporate the X Client libraries so >> that X servers can connect to it but not itself have a gui. This >> could, for example, be on a headless server. > > Is it broken right now? What improvement will we see from having to >add a "GUI" flag?
TL;DR: it's broken as hell, missing GUI, flag conflicts, implicit flags, full package.use and inability to sanely replace old toolkits with new ones. So, let's say we're considering only GTK+ and Qt, for simplicity's sake. Wrt QA policy, we only are supposed to use the following flags: gtk2, gtk3, qt4, qt5... Now, we have the major types of packages (with some GUI): 1. Packages with a single obligatory GUI -- having no flags, 2. packages with a single optional GUI -- having one flag controlling whether it is enabled, 3. packages with multiple GUIs -- having multiple flags. Now, the third type could be further split depending on: a. whether it can install multiple GUIs simultaneously, or just one of them, b. whether the GUI is obligatory or optional -- i.e. if there are flag combinations leaving you with no GUI, c. whether REQUIRED_USE is used to enforce clear choice, or multiple flag combinations are collapsed implicitly. That's there packaging theory. Now let's say that we have a user who wants to have GUI built whenever possible, and prefers GTK+3 for some reason. Now, if he sets: A. */* gtk3 he will get some packages with GTK+3 GUI, some packages with other GUI, some packages with no GUI at all and some packages telling him to enable another flag. Let's say he underwent the effort and enabled gtk2 on some packages, qt5 on some other. Now, when packages gain gtk3 support, he either gets new conflicts or two flags being enabled cause app to prefer one of them. When packages gain qt6 support, he is stuck with 5 until support for 5 is removed. Even though some packages start using 6 implicitly anyway. B. */* gtk3 qt5 This covers packages not supporting GTK+ better but leaves multiple GTK+ problem unsolved. But now, some packages will either request him to disable one of the two, or implicitly choose one of them, possibly the one less preferred. C. */* gtk2 gtk3 qt5 Because he is tired with a lot of packages not supporting GTK+3. Now, he's either in a world full of conflicts, or implicit choices. For the latter, he's unhappy that some developers make him prefer old GTK+2. Of course, that are just the closest user facing problems. Additionally, every time developer refuses to use REQUIRED_USE, the user is left with some implicit choice whose result can't be predicted, possibly slow and unreadable pkg_pretend that actually tells him about the choice (too late), and multiple meaningless flag combinations that make it impossible to reuse the same binary package even though the same GUI has been actually used. I'm not saying that 'gui' solves all the problems. But it's a step in the right direction where USE flags actually start meaning something and not resembling the Ubuntu 'apt-get install libgtk+3 libfoo ...' -- Best regards, Michał Górny (by phone)
