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