Upcoming gtk2-engines-* insanity
Hi all,
While working on the Ubuntu development branch, we've hit a little snag with
the gtk-engines and gnome-themes packages, which will land on Debian's plate
soon, so I wanted to get some opinions on how to handle it such that Debian
can benefit from our suffering at the bleeding edge. :-)
The theme engines shipped with gnome-themes have all been moved into the
gtk-engines tarball, which would normally not be a problem, but gtk-engines
is 2.6.x (in line with GTK+), while gnome-themes has been at 2.6.x and 2.8.x
for a while now (and is 2.9.x right now).
This means that the gtk2-engines-* packages no longer have advancing version
numbers, in fact, they're at least two micro version clicks behind! Further
complicating the issue, gtk-engines has integrated a couple of engines that
were previously (and perhaps still are) maintained separately.
Here's a quick tour of our options:
* metal and redmond95 are simple, because they're still maintained in
gtk-engines, and are upgraded for 2.2.x to 2.6.x.
* pixbuf has moved from gtk-engines 2.2.x to gtk+ 2.6.x, so that's no
problem.
* crux, highcontrast, lighthouseblue, mist and thinice are troublesome, as
they've moved from gnome-themes 2.[89].x to gtk-engines 2.6.x. We could
set an epoch and track the gtk-engines version numbers (ie. 1:2.6.0-1) to
solve this.
* industrial and smooth seem to be maintained separately, so we could just
ignore the gtk-engines versions and use the original upstream releases,
or we could use the code in gtk-engines but version the binary packages
correctly as per the upstream versions (which I'm attempting to convince
the gtk-engines maintainers to document regardless).
For what it's worth, I'm also seriously considering switching gtk-engines to
use cdbs in Ubuntu. 8)
Thoughts?
- Jeff
--
linux.conf.au 2005: Canberra, Australia http://linux.conf.au/
All this self-centred cock-handling is totally where it's at.
Reply to: