[gentoo-desktop] Re: Use flag changes

[Duncan]

=?ISO-8859-15?Q?R=E9mi_Cardona?= <remi2402@××××.fr> posted
44B5ED4A.8080104@××××.fr, 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

-- 
gentoo-desktop@g.o mailing list