Thursday, September 08, 2005

» My packager's gripes with GTK and GNOME

James says: "The major gtk2 upgrade was very important between betas 2 and 3, and would have had API/ABI backwards compatibility". I have absolutely no problem with the 1st part, I mean.. hey, it's a beta ;) Great to include the latest available version. But what was actually breaking packages built on beta2 was the major cairo upgrade, then shipping instead of Personally I'm really not convinced about GNOMEs backwards compatibility. I've seen too many users send me too many mails because of major issues they had after upgrading some GTK or GNOME package. Take it or leave it, but KDE proves to be much more stable regarding that, at least from my humble experience. My major gripe with GTK and GNOME is the naming of the libraries. Why on earth is the shared library in gtk2-2.6.x called and the shared library in gtk2-2.4.x called... you bet.. as well ? 1) either it's supposed to version the ABI, and then it would only make sense if GTK 2.8.0 was ABI-compatible with GTK 2.0.0 (are you kidding me ? ;)) 2) or.. well.. a wrong decision that doesn't make any sense ? Because of that, it's not possible to install e.g. GTK 2.4.0 and GTK 2.8.0 side-by-side. Almost every file that's part of GTK and GNOME libraries is versioned (pkgconfig, shared libs, include directories, ...), but they're all versioned with -2.0. I mean, everything is there, technically, to have several GTK and GNOME versions at the same time on one host, it just fails because the GTK/GNOME developers keep calling it "2.0" (instead of 2.0, 2.2, 2.4, ...). Why would someone want to have 2 GTK versions installed at the same time ? Well, I maintain packages for SUSE Linux 10.0, 9.3, 9.2, 9.1 and 9.0. Very often, projects that use GTK and GNOME rely on features only available in the very latest version (often even unstable development versions), and there's just no way I can provide e.g. GIMP 2.3.0 on SUSE Linux 9.2, 9.1 or 9.0. Can anyone enlighten me on the reason for that file/library naming scheme ?


Anonymous Anonymous said...

GTK+ 2.4 should install a file, while GTK+ 2.6 should install a file.

From the shared-library side of things, they share the same library name (, the same primary version number (0), and differ in the minor version number (400 vs. 600) and the revision number (14 vs. 7). This is how shared libraries should be versioned -- if the major number is the same, then upward releases should be ABI compatible. This is intentional, as GTK+ has a stable ABI.

GTK+ 2.8 is ABI compatible with GTK+ 2.0, and all GTK+ 2.0 apps should run unchanged under GTK+ 2.8, no kidding needed. If that isn't the case, then that's a GTK+ 2.8 bug which should be fixed.

It should be possible to install the GTK+ 2.4 and GTK+ 2.8 libraries in parallel, since the fully-versioned library names differ, but the RPMs frequently include the .0 symlink as part of the package, leading to package conflicts. This is a packaging problem; installation from source would permit parallel installs of both versions.

Blogger Loki said...

Thanks for the information, Jonathan.
If GTK is effectively ABI backwards compatible with previous releases on the same major version, then the file naming makes sense indeed.

And there's probably the nasty little bugger: "but the RPMs frequently include the .0 symlink as part of the package, leading to package conflicts"

I'll try to find so time to have a deeper look at it.

BTW, congrats for your baby, you're almost 4 months ahead of me ;)


Post a Comment

<< Home