RFC: rpm auto-glib version enforcement

[Owen Taylor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050320/7ea0f69f/attachment.sig>