Re: [Boost-build] Boost library naming scheme

From: Steve M. Robbins (steve_at_[hidden])
Date: 2008-04-14 01:57:21

On Sun, Apr 13, 2008 at 11:43:49PM -0500, Rene Rivera wrote:
> Steve M. Robbins wrote:
> > On Sun, Apr 13, 2008 at 11:04:35AM -0500, Rene Rivera wrote:
> >> Steve M. Robbins wrote:

> Am I to surmise from below that you change the version numbers of all 
> libraries when this happens? Hence forcing users to recompile to account 
> for the ABI change?

No.  Debian is not in charge of the library version number, so it
does not change.  We simply package the same library version with
a different package naming scheme and make them conflict.  

> >> Are users forced to recompile all their code?
> > 
> > Effectively, yes.
> > 
> > When Debian rebuilds a library due to an externally-forced ABI change, we
> > produce a different package but since both the old and new packages install
> > the same library file they must conflict.  In some cases, you can simply
> > refuse to install the new library package and continue using your old code.
> > However, for a library (like Boost) that is used by other packages, you'll
> > quickly be forced to install the new version and rebuild your local code.
> 
> Hm... So you also uninstall the older package for the ABI change?

The packages conflict so you can have either the old or the new
library, but not both.

> If so, 
> how do you support binary only, aka commercial, packages? Do you wait 
> for the providers to rebuild them? Or are they unusable as soon as the 
> user upgrades?

If the vendor provides a debian package that participates in the
dependency graph, the user is notified of a problem as soon as she
tries to upgrade: the removal of the old library package will force
removal of the commercial package.  The user then has the option to
accept this or back out of the upgrade.

If the vendor does not participate in the dependency graph, there is
nothing Debian can do.  It will be broken as soon as its required
packages are removed (for whatever reason).

> > With respect, that's backwards.
> 
> Doesn't seem any less backwards, i.e. arbitrary, than putting the number 
> only at the end :-)

It's backwards from established convention.

> > The conventional scheme, as I
> > outlined, is to put the library version in the SONAME but not in the
> > "link name".  That is, (for a single-threaded non-debug variant) the
> > library file name (and SONAME) is:
> > 
> >     libboost_qwerty.so.1.35.0
> > 
> > while for the linker there is the symbolic link
> > 
> >     libboost_qwerty.so --> libboost_qwerty.so.1.35.0
> > 
> > so that you can use "-lboost_qwerty" not caring about what version is
> > installed.
> 
> Why would it matter at all what the original name of the library is, if 
> the point seems to be to only access it as the undecorated name?

That is not the point.  Both names are used: the link time name is
"libboost_qwerty.so" (-lboost_qwerty) but the run time name is
"libboost_qwerty.so.1.35.0".

If you're perverse, sure you could choose a random runtime name, but
I'm not sure what you're getting at.  I described the mechanism in
some length in http://lists.boost.org/boost-build/2008/04/18835.php
and am happy to clarify any confusing points; just ask.

> > This is established convention in linux, so I don't understand why
> > you'd want to do anything differently.
> 
> I know I'm being a pest on this... But I'm not much for unreasoned 
> conventional practices. As for the reason it's the way it is... Because 
> we want to support about 7 different operating systems with, ideally, a 
> single consistent naming scheme. So as to reduce our testing and support 
> permutations with the goal of giving users a high quality product. 

That's a laudable goal.  But let me ask: does this force you to embed
the version number twice in the library name?  Surely once is enough?
If once is enough, then you have many options; however, one option has
the benefit of being established convention ...

Regards,
-Steve