=?ISO-8859-15?Q?R=E9mi_Cardona?= <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 13 Jul 2006 08:50:50 +0200:
> First off I'd like to say this is a real question and not an attempt to > spur endless trolls and flames. Appreciated. =8^) > We currently have qt, gtk and gtk2 use flags. Recently, the qt3 and qt4 > use flags were introduced to get rid of the original qt flag. Now reading > bug 137785 (after reading Cardoe's blog) it seems the gtk and gtk2 flags > are being merged. > > What's the rationale behind this move, instead of having gtk1 and gtk2 > (which makes possible room for gtk3 whenever gnome folks feel like > branching)? > > Thanks for any additional info :) You'll probably get a shorter explanation from someone else as I know this is long. That's just the way my posts tend to be. If you prefer the shorter one to this one, well, don't bother with this one. <g> Some folks seem to prefer my long explanations, however, so take your pick! =8^) The gtk decision was hashed out on the devel list (which I try to keep up with to follow just this sort of thing, even if I'm only a user) some time ago -- far earlier than the qt flag discussion. The deprecation of the gtk2 USE flag has been ongoing since then, as new ebuilds stabilized and old ones move of of the tree. You can of course check the archives for the details if interested. =8^) Part of the reason for the different treatment of the gtk/qt versions in terms of USE flags is the difference in how the toolkits themselves are used, in terms of where support for them is optional. (Note that USE flags by definition do /not/ affect dependencies where support is not an option, but mandatory. If you emerge a package with mandatory dependencies, you always get them, regardless, and a USE flag wouldn't make much sense. That's why xorg/gtk/qt/other are often pulled in even if the USE flag is turned off.) With certain notable exceptions (poppler), packages that have optional qt support tend to support one major version at a time. They stick with qt3 until they decide to upgrade to qt4, then they upgrade and drop support for qt3. No version of the package has support for both. As well, qt upgrading tends to happen relatively faster -- it's quite unlikely there will still be packages in the double-digits still requiring qt3 years after the biggest project (kde) switches, as has been the case with gtk. (xmms for one is basically dead upstream and will never switch to gtk2, while the forks already made their switch but don't have the wide userbase or plugin support.) The story with gtk is of course quite different, in part because of the differing upstream structure. While qt is supported by a single for-profit company (tho it's available in GPL) which encourages keeping in sync with that company to continue to get support, gtk is a much wider community process, without the same forces encouraging upgrade. It's much more common for packages to have multi-version gtk support, as the old versions continue to be used and supported by the community itself long after the upstream core has moved on. The LGPL nature of gtk also affects things, as slaveryware companies using it don't have that extra push to upgrade to maintain their paid support that qt does, and they may often be of the attitude that you don't break what's working well for you. Thus the dynamic is quite different. It makes less sense to have a single global qt flag, because the versions are rather more independent of each other, few packages support both at the same time, and the two versions can therefore almost be treated as two entirely independent toolkits in terms of USE flags. Practically, the difference between qt3 and qt4 dependiencies is almost as wide as that between qt3 and gtk, thus justifying the separate USE flags. gtk, OTOH, is much more clearly interrelated, packages that support the earlier version are likely to add support for the later version before dropping support for the early one. Conversely, while both are often supported, there is seldom a point at which one is not definitely preferable to the other. Early in the major-version cycle, gtk2 wasn't considered all that stable, it didn't have a lot of adoption yet, and gtk1 was the obvious preferred choice in most cases. At some point however, gtk2 stabilized enough and enough packages added support for it that it made sense to prefer it. Thus, gtk2 is now the generally preferred (and default) Gentoo choice when support for both is available, if neither are merged. (Often, however, a package may choose to let gtk1 fill the dependency and build against it, if it's already merged but gtk2 isn't. That's up to the individual package maintainer, I believe, based on the idiosyncrasies of an individual package.) There's also a bit of Gentoo history involved. In hindsight, the implementation of the gtk/gtk2 USE flags was *VERY* confusing for a *LOT* of users. It simply wasn't intuitive. That gtk meant support for gtk in general, while gtk2 only meant prefer gtk2 where there was a choice, simply wasn't the way most people expected it to work. They expected gtk to mean gtk1, gtk2 to mean gtk2, but that's not how it was implemented at all, and it resulted in serious user confusion and uncounted bugs and forum/list posts over the gtk2 flag active period. The discussion on the dev list that I mentioned earlier determined that now that gtk1 was finally beginning to age out, as maintainers began defaulting to gtk2, it was time to grasp the opportunity and correct that mistake. As the gtk2 flag already had a given meaning that had been drummed into user's heads for so long, it simply wasn't practical to change it to /now/ mean what users intuitively /thought/ it meant all along, after they'd finally been educated out of it. Given the above reasoning about how gtk works (qt hadn't yet entered into the discussion), it was decided that the simplest thing to do would be to drop the gtk2 USE flag and let the package maintainer decide what was best for an individual package, with a policy now favoring gtk2 where there was little difference in support. The decision was considered future-proof in that when gtk3 comes out, each individual package will still likely have a best choice, and Gentoo as a whole (practically, the gtk herd maintainers will make the recommendation, which would then be discussed on dev when the time came, before an overall policy chance was decided) will continue to default to gtk2 by policy until such time as gtk3 is considered stable and widely used enough to change that default. It was in the context of that decision, as well as the long history of the mistaken earlier gtk decision, that the qt discussion took place. Given that there wasn't already a global qt4 flag that meant something else, when enough packages got local qt4 optional support to be worth considering, someone initiated the discussion that resulted in the split qt3/qt4 USE flags. The qt folks were able to take the lessons learned from the gtk debacle and apply it to the discussion and ultimate decision BEFORE the qt4 flag was used by enough packages to make it impractical to change should the decision warrant it. Had there already been a global qt4 flag, as there was a gtk2 flag, the outcome of the discussion would have been quite different, as there wouldn't have been the flexibility to choose what worked best, a choice having already been made by default. As it happens, tho, due to the different usage of gtk and qt, the different handling does make sense to some degree, and the gtk/gtk2 resolution might have ultimately been similar, even if gtk2 didn't have the long history it already had by the time the latest policy was decided. (BTW, I haven't mentioned when that gtk discussion was, as I don't remember for sure, but it was either late last year or early this year, IIRC.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
