GNOME Bugzilla – Bug 324336
Please provide a mean to expose the build or package version in the API and ABI
Last modified: 2005-12-19 14:32:37 UTC
Hi, This bug is a request for the addition of an "extra version" information to the Gtk API and ABI, so that a function call could return the version of the Gtk library package the program runs against. This is in response to the following story (<http://bugs.debian.org/334534>): - Gtk 2.6.4 releases - Debian packages 2.6.4 close to its next stable release - an important bug in Gtk 2.6.4 is discovered in low-level keyboard handling, a patch is proposed to the GNOME BTS - Debian includes the patch in its package, which is now part of its stable release: that fixes the behavior for numerous apps - Eclipse releases with a work around for Gtk 2.6.4 because some distros have unpatched Gtk 2.6.4, but this work around causes breakage when the patch has been applied - Eclipse complains to Debian that the patch should be reversed because this ain't truly Gtk 2.6.4 Now, there's no way for Debian to revert that patch, update Gtk to a newer upstream, or change the reported Gtk version in a deeply frozen release such as sarge; only minor updates are permitted, and any of the options we have would require other programs to work around the bug (as Eclipse does) too. I proposed the Eclipse developers to not only check whether Gtk is in version 2.6.4, but also to check they are on a Debian system, but they didn't react to this, I believe this is because they find it ugly to add some other means of checking such as calling commands, or reading files, than just checking the Gtk version. This is why I propose the addition of a distro / build information function, which would permit the kind of advanced recognition of the Gtk library that Eclipse does to be more fine-grained. This is very similar to the User-Agent of Debian browsers which sometimes include the package version. Please let me know what you think of this while I point the Eclipse people to this report for them to comment. Thanks,
What exactly prevents Debian from switching to 2.6.10 ?
We're usually not allowing new upstream releases in security or stable uploads, especially in such core libraries with so many reverse dependencies.
That policy should be revised, for projects which actually maintain a stable branch with a conservative bugfix only policy (like GTK+), not allowing new releases based off that branch doesn't make much sense.
I don't think that Debian wants to update a library on which 1624 depend directly (this is without counting the bindings), especially with 1411 lines of ChangeLog. Updating fetchmail, or patching libgnomeprint is possible, but not gtk. Besides, that wouldn't change the main problem which has nothing to do with updating the Gtk in Debian but distinguishing slight variations between Gtk builds between systems or distros. (I do agree that if Debian could update to 2.6.10 by the effect of a magic wand, the Eclipse problem would disappear. The fact is Debian can't. I'm trying to avoid Eclipse or others being stuck like this in the future.)
What you're saying is effectively the Debian gtk+ package maintainer has a better idea of what should be considered "stable" than the gtk+ developers themselves. It's not like the package is completely frozen, patches are cherry picked with no real policy behind them. Conceptually, this arbitrary distro ID seems like a very brittle idea, since it's completely opaque as to what having a "Debian" gtk+ actually means, and that meaning can change over time. It's not really better than checking if /etc/debian_version exists and changing behavior based on that. It's still weird special casing. Adding an extra version API call won't help you in this immediate case either, since new API isn't going to be added to 2.6 or 2.8.
What you're saying is effectively that updating Gtk to a newer stable upstream release won't cause any new bug in thousands of packages and we can roll it out on ten of thousands machines without any risk of breaking at any place in the world, with any setup of the world. Nor the Gtk team, nor the Debian maintainers, nor a testing team can represent all the combinations of configurations that can be used. How many people are, say, testing Xinerama before a stable Gtk release? Anyway, I don't want to debate whether all distros should simply stick to the .tar.gz as released by the Gtk team, without any patch whatsoever: it won't happen. Even if it envisageable for small projects, it isn't anymore past a certain size. Also, this is not about *bugs*, there are not only bugs that can change the behavior of Gtk. Configuration flags, customization patches (eg for integration with other apps), or simply build environment can change between distros or installs of Gtk. What I propose is that some representation of this be added to permit the recognition of these variations, much like the User-Agent can be used to guess capabilities of a browser. Mozilla offers the possibility to expose in the UserAgent a vendor (in my case it's "Galeon") and a subvendor (in my case it's "2.0.0 (Debian package 2.0.0-1)"). This doesn't need to be very complex, it's simply a place holder for information on the source changes and build conditions to be set by the packager or whoever needs to update it. Imagine things such as "(gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5))" inserted by default from gcc -v, or "(Debian 2.8.9-2)". I can understand the API won't be available right now, this is a proposed mid/long term tool, please consider this only by its usefulness, not by the date when it will be available.
Will not happen.
Not saying distros should stick to the tar.gz, just saying that Debian's cherry picking of patches doesn't confer any more stability guarantees than updating to a newer version. Either way, you're introducing a change that risks breaking things. Why are you trusting the package maintainer's opinions of what's a "safe" change over the upstream maintainers? The stable branch really doesn't change that much, so the work to integrate any customization patches should be very small. Note this is simply a recommendation to move from one 2.6.x to another 2.6.x, not 2.6.x to 2.8.x. As for the extra version API, your comparisions to Mozilla and GCC are not valid, because those version strings are merely informational for humans; nothing machine automated uses those to change behavior. Hardly anyone is going to make a Mozilla extension that special cases things automatically based on whether it's a Debian mozilla or not, because hardly anyone is going to keep track of whether Debian mozilla 2.0.1-5 fixes this bug, and 2.0.1-7 fixes some other bug, and RH 2.0.1-4 fixes the same bug as debian 2.0.1-5. It's just opaque numbers, they don't provide any actual meaning by themselves, so it's simply not something usefully maintainable.
I feel there are some inaccuracies being reported by both sides in this bug report, so I feel I should clarify. From Debian: The patch Debian applied to GTK+ was a low-level focus fix. It is risky to change how low-level X events are handled on a stable stream. The practice of backporting patches in distributions makes it challenging for ISVs to create quality products. I agree with the last paragraph in comment #8: ISVs don't want to write special case code for each distribution*. From GNOME: It is exceptionally risky to change how low-level X events are handled on your stable stream. In this case, the patch was applied to 2.6.8. It might have been safer to apply this patch to the GTK+ development stream. At the very least, it might have sent a clearer message to distributions about the the potential problems it could cause. * There are a lot of different GTK+ versions. There are a lot of different window managers. Every interaction can cause breakage. It makes our lives a lot easier if a third dimension isn't added: lots of different distributions.