8/26/2005
GTK+ USE flag hell
Here’s the solution to the GTK+ USE flag issue. The final solution because I’m tired of all the debate and in-action on the mailing lists I am posting this here. I hope we can quickly discuss it and dismiss all issues with it and I can implement it this weekend while I am being mauled by the hurricane.
Remove entirely the “gtk” USE flag. It’s ambiguous and pointless. The proper USE flags should be gtk1 and gtk2. Turn off gtk1 for the desktop profile and leave gtk2 on in the desktop profile by default. As far as I’m concerned, GTK+ 1.x is depreciated and does not need to be pulled in needlessly.
What’s that mean? If you want any GTK+ support, you turn on gtk1 and gtk2 in your USE flags. If you only want GTK+ 2.x support, you turn on gtk2 in your USE flags and leave off gtk1. If you want only GTK+ 1.x support, you turn on the gtk1 and leave off gtk2. If you don’t want GTK+ on your system you leave both USE flags off. Simple. Easy to understand. No ambiguity.
Oh no what about GTK+ 3.x people say. Well first off, that’s a long way off. Do they even have a roadmap that shows breaking ABI & API compatibility? Not as far as I know. But plain and simple, you add a gtk3 USE flag and it’s pretty obvious.
What about when a package supports both? Well the USE flags sort it out pretty easy.
What about when a package supports both and both are turned on? Let’s take easytag for an example. Well guess what, the maintainer knows the package well. So he/she makes an educated judgment. For example, when easytag GTK+ 2.x support first hit the streets, it was pretty experimental so it would have been wise that the ebuild maintainer make GTK+ 1.x the default if both USE flags were on. However now that the GTK+ 2.x support is pretty solid, it would be wise for the maintainer to switch to GTK+ 2.x to be the default? Why because it looks better and presents Gentoo as a desktop and a functional userbase better. Because most users are going to have a GTK+ 2.x based desktop (i.e. Gnome 2.x) if they use GTK+ and as such will have configured it to their liking and suddenly easytag will conform to their visual layout that they are comfortable with. It won’t stick out like a sore thumb like GTK+ 1.x does.
I hope this covers all scenarios and we can start making this change ASAP because it needs to happen 2 years ago.
Any questions? Feel free to post a comment here and I’ll answer it.
Filed under: General, Gentopia, Linux, Modular X
13 Responses to “GTK+ USE flag hell”
Leave a Reply
August 26th, 2005 at 6:59 am
Perfect. I don’t understand why it hasn’t been implemented a long time ago, but anyway… better late than never.
BTW, I wanted to get rid of gtk1, and I found several package dependencies (among my own installed packages) that has no equivalent in gtk2:
* glib1/gtk1 -> libmovtar -> mjpegtools -> transcode/avidemux/…
* glib1/gtk1 -> imlib -> kuickshow
* all apps that have a gtk1-based gui only (mplayer, nmap…)
How should they be handled if gtk1 is disabled in a desktop usage context? Do a user have to enable gtk1 to get these?
August 26th, 2005 at 7:14 am
Those are solid GTK 1.x depends. If a user emerges those packages it would bring in GTK+ 1.x. For the USE flag enabled builds, it would just not include GTK+ 1.x support in the tools. In fact I use mjpegtools right now without any GTK+ support because the tools I need on my system are command line based.
As for the others, some of the MythTV devs and I have it planned to take over the source tree and update them to GTK+ 2.x. But right now we don’t have the time.
August 26th, 2005 at 7:28 am
I’m glad to see something done about this. I noticed you mentioned easytag as requiring either gtk1 or gtk2, but since there are currently only versions that only work with gtk1 and ones that only work with gtk2 in the tree (but none that work with either) unless I overlooked something, I’ll take ogle-gui as another example. Currently, RDEPEND contains
!gtk2? ( =x11-libs/gtk+-1.2*
=gnome-base/libglade-0* )
gtk2? ( =x11-libs/gtk+-2*
=gnome-base/libglade-2* )
This makes sure that regardless of USE flags, it can choose some version of gtk. How would this work with gtk1 and gtk2, when neither gtk1 or gtk2 is in USE? You’d either have to write something like
!gtk2? ( gtk1? ( =x11-libs/gtk+-1.2*
=gnome-base/libglade-0* ) )
!gtk2? ( !gtk1? ( =x11-libs/gtk+-2*
=gnome-base/libglade-2* ) )
gtk2? ( =x11-libs/gtk+-2*
=gnome-base/libglade-2* )
or die when neither flag is set. The first solution is ugly and makes it easy to accidentally make changes to [!gtk1][!gtk2] without copying them to [gtk2], and the second solution means that emerge ogle-gui can fail where it would currently succeed without a problem. How would you solve this?
August 26th, 2005 at 10:33 am
I really think that this is a good idea, from a user’s point of view (being one myself). It would definitely ease the confusion over which flags pull in which versions of GTK.
I’ll even help test, if you need it. You’ve got my email from the post, so go ahead and mail me if you need a tester.
Thanks for the work here and in Gentopia!
August 26th, 2005 at 11:17 am
I’m a GTK-2 user on a system free of any GTK-1 libs. It means i have USE=”gtk gtk2″ globaly, plus ~15 “-gtk” entries in package.use for stuffs that have an optionnal dep on GTK-1 only. Your proposal would basically allow me to drop this special cases entries from my package.use, so I personnaly am all for it.
Now, on the other hand, what happens to a user who don’t like GTK in general, but still prefer GTK-2 over GTK-1 where one is really required? Currently, all he has to do is USE=”-gtk gtk2″ (plus maybe a few package.use entries for the broken packages which use “gtk2″ for enabling GTK support). But with your proposal, i don’t see what USE flags such a user could set globally. Sure he should have “gtk1″ turned off, but for “gtk2″:
- either he turns it on and will get lots of packages linked to GTK whereas it was optionnal, and thus not what he wants.
- or he turns it off and ends with some packages linked to GTK-1 when it could have been GTK-2 (whenever GTK-1 is the ebuild default, which is currently the case of ~all IUSE=”gtk2″ packages. Sure, changing this packages to IUSE=”gtk1″ is not a solution for people who USE=”gtk1 gtk2″, and changing them to IUSE=”gtk1 gtk2″ is ugly, as Harald as shown above).
I see a regression here, and lot of “read the ebuilds and set your package.use accordingly” for such users. But i don’t know how numerous they are compared to those like me who just want to easily stay away of GTK-1, so maybe it’s acceptable.
Oh, and one last thing… a solution for this IUSE=”gtk2″ case may be the future “per-package USE defaults” portage feature: if this packages where changed to IUSE=”+gtk2″ wherever it’s the recommended version, GTK-haters could simply have no gtkX flag set globally, and still have GTK-2 support prefered over GTK-1 where one is required. But that’s not a short-term solution sure.
August 26th, 2005 at 12:06 pm
> !gtk1? ( =x11-libs/gtk+-2*
> =gnome-base/libglade-2* )
> gtk1? ( =x11-libs/gtk+-1.2*
> =gnome-base/libglade-0* )
If you do so, what will be decent global flags for a user who wants GTK support wherever possible, with a preference for GTK-2 when possible (basically, what currently is USE=”gtk gtk2″, and is probably what most people are used to since it’s most profiles defaults)? If he turns on “gtk1″, he will get the obsolete version prefered over the new one, and if he don’t, he will miss GTK support in packages which only support GTK-1. Sure, adding some stuffs to package.use solves that kind of issue, but still, if users have to add 20 entries there for such a common need, it’s imho a problem (just like it is atm for another common need, GTK2-only systems).
> And it would never require a user to read the ebuild.
Sure it will. For instance, depending of the ebuild, the “gtk1″ flag will mean “use GTK-1 rather than GTK-2 for the GUI” or “build the optionnal GUI”. That’s two very different things, and only reading the ebuild or making several tries allows to know what will happen. Same for “gtk2″, sure. That was the whole point of the current gtk/gtk2 USE flags “hell” to make a distinction beetween “adding GTK support” and “prefering version X”, to avoid such ambiguities.
> If they don’t want GTK+ support then turn off the
> USE flags, if the support is manditory then it will
> pull in the necessary support.
People who don’t like GTK may still have a preference for 2.x over 1.x when one is mandatory. My point was for people who:
1) don’t want any GTK support when it can be avoided,
2) prefer GTK-2 if one version is really required.
USE=”-gtk1 gtk2″ would not be ok for because it would turn on some optionnal GTK support (breaks wish 1), and USE=”-gtk1 -gtk2″ would not neither because it would not guarantee that GTK2 is used where there is choice (breaks wish 2).
To summarize, here is what i think are the most common users’ wishes about GTK:
- no GTK1 at all, but as much GTK2 as possible (that’s my case, it was not possible without a lot of package.use, and for this one your proposal helps with USE=”-gtk1 gtk2″)
- as much GTK as possible, with a preference for 2.x where possible (that was USE=”gtk gtk2″, but i don’t see what it would be with your proposal without lot of package.use)
- as few GTK as possible, with a preference for 2.x where possible and GTK is mandatory (that was USE=”-gtk gtk2″, but i don’t see what it would be with your proposal without lot of package.use)
August 26th, 2005 at 12:45 pm
> The code then becomes…
>
> !gtk1? ( =x11-libs/gtk+-2*
> =gnome-base/libglade-2* )
> gtk1? ( =x11-libs/gtk+-1.2*
> =gnome-base/libglade-0* )
>
> And putting a nice little notice in pkg_setup() that GTK+
> 2.x is the default now if you really want to wave a flag at
> the user.
This would use gtk2 when neither gtk1 nor gtk2 is in USE, but use gtk1 when both gtk1 and gtk2 are in USE, so I wouldn’t call either gtk1 or gtk2 the default with this.
August 26th, 2005 at 1:11 pm
Maybe off-topic…
How about when all you want is a graphical UI and the app uses gtk_ as it’s particular toolkit. Should the USE flag be gtk_ or X? e.g. to enable GUI for unison one has to USE=gtk, but I think it would make more sense to USE=X. On the other hand, for mplayer, USE=X (I think) just means that it can display a no frills playback in X, but USE=gtk means that it should build a crappy GUI (”gplayer”?).
Maybe there should be a USE flag for GUI, and the maintainer decides what toolkit is used by default (and user can override with gtk1, gtk2, kde, etcetera if there is a choice).
August 26th, 2005 at 1:14 pm
Harold, the issue is fairly simple. We make GTK+ 2.x the default setting and change the USE flag to be gtk1 and default to GTK+ 2.x support. ogle-gui requires either GTK+ 1.x or GTK+ 2.x, so let’s make the default GTK+ 2.x. The code then becomes…
!gtk1? ( =x11-libs/gtk+-2*
=gnome-base/libglade-2* )
gtk1? ( =x11-libs/gtk+-1.2*
=gnome-base/libglade-0* )
And putting a nice little notice in pkg_setup() that GTK+ 2.x is the default now if you really want to wave a flag at the user.
Anonymous, I don’t really see how this is much of an issue. And it would never require a user to read the ebuild. A simple emerge -pv pkg and it would show the user the USE flags.
If they don’t want GTK+ support then turn off the USE flags, if the support is manditory then it will pull in the necessary support. That’s how it works now and that’s how users should have their USE flags set now. Nothing different.
August 26th, 2005 at 1:16 pm
Anonymous #2, I’m not proposing to change the other USE flags, just GTK’s. So however each package has it setup. In mplayer’s case you’d have to use the gtk1 USE flag.
August 26th, 2005 at 1:42 pm
[…] Doug Goldstein « GTK+ USE flag hell […]
August 28th, 2005 at 5:31 am
Great. As a user who has used Gentoo since 1.3 days I can only say that this is the way it should be done and should always have been done.
Yes, I can imagine there will be problems with certain ebuilds - but this should not keep a good thing from happening. There are probably more potential problems with the way that gtk/gtk2 is handeled until now. And if it’s only usability from a users point of view…
August 28th, 2005 at 11:32 am
Good thing, really.