On Sun, 2005-03-20 at 16:45 +0100, Axel Thimm wrote: > > Thoughts? > > Is this feasible to implement in a clean way? > > Will this fail in any corner cases? > > Supporting a broken library versioning scheme by automated rpm > workarounds doesn't sound like a good idea. You are better off trying > to educate upstream authors to start bumping up the major version > every decade or so ... > > If you start doing so with glib2 you'l have to do the same with pango, > gtk2, atk, ... (... doesn't stop ...) Why would we change the major version of GLib when we haven't broken binary compatibility? As you say, if you change the major version of GLib, you have to change the major version of *every single library that depends on glib*. We're not going to do that. Using new symbol versions for the symbols we introduce in new versions of GLib would be a nice touch and would help RPM figure things out; but: - It can't be done retroactively. There's no way (save ugly and inefficient alias hacks) to introduce symbols for GLib 2.2, 2.4, 2.6 - It's hard to do in a way that won't break the build on non-GCC, non-ELF platforms without support in libtool. But if someone wanted to tackle making the GLib symbol handling yet more complicated to get versions for 2.8 symbols, I think it could be a useful (upstream) contribution. > > [1] > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149190 > > This is unrelated to the above RFC, but if I understand this correctly, > > glib2-2.6 g_stat() changed in such a way that breaks ABI forward compat. > > Somebody that knows glib better can verify or explain this? Or maybe > > it was already fixed upstream. http://bugzilla.gnome.org/show_bug.cgi?id=167942 maybe. g_stat() is new in 2.6 so there's clearly no backwards/forward compat problem, but there was a problem if the app and library didn't match in terms of large file support. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part