Re: libgailutil.so.16 -> libgailutil.so.17

[Owen Taylor <otaylor redhat com>]

James Henstridge <james daa com au> writes:

> Sander Vesik wrote:
> 
> >On 26 Jul 2002, jacob berkman wrote:
> >
> >
> >>>I think you'd want to do this if you added API, would you not?
> >>>
> >>i wouldn't.  that would mean apps/libs having to be re-linked against
> >>the new lib, which breaks bin compat for all libs above me.
> >>
> >>
> >
> >Why would you link to the so.xy and not to the .so ? As there are no
> >minor/micro versions in teh numbering, libgailutil will need to become
> >libgailutil2 (or 3 or ...) when incompatable chanegs are introduced.
> >
> Should we start looking at ELF symbol versioning?  It is designed to
> handle this sort of issue -- not bumping the soname (which breaks old
> apps), but allowing newer apps to exit immediately if the library
> doesn't contain the required version nodes.

First, a general comment on symbol versioning:

ELF symbol versioning is over-hyped.

Canonical example of symbol versioning is that the C library wants
to change the size of 'struct stat', so you have a symbol 
stat NEW VERSION that operates on the new stat structure
which new apps use, and old apps still use the old version
of stat().

So, what happens if a library (not the C library) uses 'struct stat'
somewhere in it's interface - it has a 
my_virtual_stat(struct stat *statbuf) if a newly
compiled app uses an older copy of the library - the new app
will expect the new stat structure, the old library the old
stat structure. 

s/struct stat/GtkWidget/ and you see why symbol versioning just
isn't practical for an object oriented library.

Avoiding compatiblity problems is real simple:

 - Make everything as opaque as possible
 - Add padding where it makes sense
 - Just don't make incompatible changes.

Where I think some symbol versioning tricks might be possible
is something like Pango's relationship to FreeType -- Pango
uses internal interfaces in FreeType, so I'd like to
be able to say:
 
 libpango.so depends on libfreetype.so.6
 libpango.so depends on libfreetype.so.6(INTERNAL_API.v653)

So package tools (etc.) could figure out dependencies without
forcing a change in FreeType's main soname.

I think what James is suggesting is something similar - to,
e.g., give all symbols introduced in GTK+-2.2 a new symbol
version so that it's easy to tell whether an app linking
to libgtk-2.0.so.0 (the soname for GTK+-2.2 as well as GTK+-2.0)
requires GTK+-2.2 or just GTK+-2.0.

It would be neat, but also a fair bit of work and a portability
snag. And it doesn't catch cases where the API is implicitely extended
-- e.g., a combination of arguments that was an error in GTK+-2.0
works in GTK+-2.2. 

I think the concept of the "minor" version is probably more workable
in practice. Something linked against libgtk-2.0.so.0.x.y
requires a libgtk-2.0.so.0.x'.y' where x' >= x.

ELF versioning schemes typically have minor version numbers
but don't do anything with them. Libtool's versioning scheme
will set the minor numbers appropriately when the system
supports them.

Regards,
                                        Owen