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

[jacob berkman <jacob ximian com>]

On Fri, 2002-07-26 at 15:33, Bill Haneman wrote:
> On Fri, 2002-07-26 at 18:21, jacob berkman wrote:
> > On Fri, 2002-07-26 at 15:14, Bill Haneman wrote:
> > > On Fri, 2002-07-26 at 18:09, jacob berkman wrote:
> > > > On Fri, 2002-07-26 at 14:15, Bill Haneman wrote:
> > > > >
> > > > > it's also true that
> > > > > backwards-compatible changes will be happening in various libraries, and
> > > > > in such cases we should bump the soname also, even though bincompat
> > > > > (backwards, not forwards) is maintained.
> > > > 
> > > > either i am confused, or you are.
> > > > 
> > > > why would you change the soname for bin compat changes?
> > > 
> > > 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.
> 
> only if the libs "above" the rev-ed library actually need the new API...
> the ".so" aliasing should take care of much of this...

it doesn't:

[jacob tpx jacob]$ ldd /usr/bin/yelp | grep gail
	libgailutil.so.17 => /usr/lib/libgailutil.so.17 (0x40b39000)

so, if i had dropped that binary on a gnome 2.0 system which only had
.so.16, it would not run.

anyway, in this case, it doesn't matter as nothing above gail is
"stable" in a bincompat case.

however, if just apis were being added there is no reason to change the
soname.

although now i am getting confused between soname and sonumber.

anyway from glib/configure.in:

        # The following version number definitions apply to GLib,
        GModule, GObject 
        # and GThread as a whole, so if changes occoured in any of them,
        they are all
        # treated with the same interface and binary age.
        #
        # Making releases:
        #   GLIB_MICRO_VERSION += 1;
        #   GLIB_INTERFACE_AGE += 1;
        #   GLIB_BINARY_AGE += 1;
        # if any functions have been added, set GLIB_INTERFACE_AGE to 0.
        # if backwards compatibility has been broken,
        # set GLIB_BINARY_AGE _and_ GLIB_INTERFACE_AGE to 0.

that plus the libtool version stuff in there will let libtool just Do
The Right Thing.

anyway i could still be confused.

 - jacob