James Richard Tyrer
tyrerj at acm.org
Tue May 30 02:24:11 BST 2006
Thiago Macieira wrote:
> James Richard Tyrer wrote:
>> This makes one wonder about the binary incompatibilities in GNOME 2.14.
>> How does the LSB deal with this? Specifically: GLib 2.8.x vs. 2.10.x
>> and GTK+ 2.8.13 vs >= 2.8.14. Is this an issue, or did GNOME just make
>> a big mistake that they need to correct?
> I'm not sure you're grasping correctly what binary (in)compatibility is,
> judging by your comments.
Sorry for my brief comments. I can right a book if you want. :-)
The Thunderbird binary version 18.104.22.168 Acrobat Reader 7.0 work correctly
with GTK+ version 2.8.13 but if you upgrade GTK+ to version 2.8.17 they
fail to start and report an error. I presume that this is binary
incompatibility. It also breaks Firefox which I built from source and
don't know if rebuilding against the new version will fix it but it will
still be a binary incompatibility.
> If we go down to the lowest level, binary compatibility is such that no
> symbol that previously existed and was public ceases to exist and the
> layout of any data structures remain the same.
And that gets to the second point. If you have GTK+ version 2.8.13 and
GLIb version 2.8.6 installed from binaries and you want to upgrade to
GTK+ version 2.8.17 you are going to have to have some dependency
tracking other than just the LSB version since GTK+ version 2.8.17
requires GLib version >= 2.10. This would also appear to be a binary
incompatibility and it appears to be a case where installing RPMs based
only on the LSB version isn't going to work when you go to upgrade.
Even if you don't use any of the new features in the GTK+ upgrade, you
are still going to need something new in GLib 2.10.
But it gets worse. GLibc 2.10.x breaks aRts (reports: "Invalid
argument") and, it appears some other stuff but this may be related), so
I find myself with a rather large mess which I think is caused by binary
More information about the kde-core-devel