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

[Havoc Pennington <hp redhat com>]

Bill Haneman <bill haneman sun com> writes:
> 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?
> 

No way, nooooooooo. Very gratuitous creation of pain for everyone if
you do that.

The soname changes if and only if you _break_ back compat.

Just check the libtool manual, it explains what to pass to libtool
-version-info, I have a summary in comments in the GConf configure.in:

    dnl libtool versioning for libgconf

    dnl increment if the interface has additions, changes, removals.
    GCONF_CURRENT=5

    dnl increment any time the source changes; set to 
    dnl  0 if you increment CURRENT
    GCONF_REVISION=0

    dnl increment if any interfaces have been added; set to 0
    dnl  if any interfaces have been removed. removal has 
    dnl  precedence over adding, so set to 0 if both happened.
    GCONF_AGE=1

Follow the libtool directions and you'll be fine.

Note, adding API also causes pain, and generally indicates that you
are sticking features into the feature-frozen stable branch as
well. This is why GTK+ has a policy against adding API in stable
versions. It's not as painful as breaking ABI but still you should
have a Very Very Good Reason.


Keep in mind that if you change your soname, and an operating system
has shipped with your library, the operating system then has to ship
compat libs for not only your library, but all libraries that depend
on your library. So for example if you break libgail ABI after Red Hat
has shipped it, we have to create extra legacy copies of libgail,
libeel, libgtkhtml2, etc. etc. - the extra copies here aren't for
developers (these aren't platform libs), but rather for the
convenience of users who may have installed stuff that uses them.  If
every lib in the stack breaks ABI once per 3 months, and there are 5
libs in the stack, we still have 5 extra copies of the stack built up
in only 3 months. So changing soname is not to be done lightly or
often, at least for libs at the bottom of stacks. Libs that are
totally internal that nobody is using, like libgnomedesktop, are less
painful to change than libs that are linked to by apps (as libgail
effectively is due to the libgtkhmtl/eel usage I guess).


As an aside, I've noticed that lots of modules' configure.in have a
habit of forcing the latest version of a library that was available
when the tarball was rolled; this is really not a practice we should
continue. You should only require a new library version if you
actually know you need it for some reason, not just on "latest is
greatest" principle. gnome-panel seems to do this for example. Good
practice prior to the stable release, dubious practice afterward.

Havoc