[pkg-boost-devel] boost's sonames change too often

[Steve M. Robbins]

Hello Jay,

I appreciate your concern.  Boost is, indeed, a challenging
beast to maintain.


On Fri, Nov 07, 2008 at 04:55:20PM -0500, Jay Berkenbilt wrote:

> As you surely know, the boost libraries are a perfect example of how
> not to handle shared library sonames.  They break one of the most
> basic rules by putting the software version number in the libraries'
> names.

Are we talking about the SONAME here or are you referring to the LINK
library name; i.e. that you link using -lboost_regex-gcc41-1_34_1 ?

I consider the second problem as solved.  Debian and several other
unix packagers (e.g. Redhat, Suse, FreeBSD) strip out the version from
the link name using packager-specific hacks.  There is ongoing
discussion on the boost-build list to push this upstream.

In the remainder of this, I assume you are talking about the
frequent change of SONAME.

I believe that the Boost view of this is the following.  C++ is
notoriously hard to keep ABI compatibility.  There is no-one willing
to audit the code each release to certify that the resulting libraries
are ABI compatible with the previous release.  Therefore, the ABI is
considered to have changed on each release.  Therefore, using the
source version is a convenient way to distinguish them.

This point has been raised on the boost list before.  Above, I'm
paraphrasing what I remember of the response.


> Even so, if I were to make my software depend on boost,
> I would have to get tangled in a needless library transition whenever
> the boost package had been updated.

That was the case when there was a single Boost source package.  Now
we have a different source for each major release.  So you can
continue using boost-regexp1.36-dev even when Boost 1.37 is uploaded.
The transitions are under your control.

In theory.

Now that Boost has moved to a quarterly release and look like they
might actually stick to the schedule, we're facing a lot of potential
boost packages.  So we'll need to cull older versions regularly.  The
present plan is to upload 1.37 soon (maybe this weekend); then, once
Lenny is released, we'll try to remove boost (version 1.34.1),
boost1.35, and maybe boost1.36.  That's going to force some packages
to transition.

We might have to revisit the packaging strategy.  Ideas on this
point are welcome.


> As you may have seen in the 1.37
> release announcement, only a handful of libraries were changed from
> 1.36, yet everything would have to be rebuilt.

There is a subtly different point here: it is a nuisance that Boost
versions all the libraries together, rather than individually.  I
hadn't thought of the problem in that way before, and I don't recall
seeing such a discussion on the Boost lists.

However, I think the Boost answer might be the same: where is the
manpower to audit each library?  It might be the case that a
simple "svn diff" shows zero changes for a given library.  That
case would be easy.  But does it happen often enough to justify
(to the Boost Release Managers) a radical change in release
strategy?


> I understand that boost upstream is using a different build system
> (bjam) that works on Windows, Mac, and other platforms [...]
> It seems like taking the easy way out while
> causing a lot of trouble for packagers.

Certainly, but put yourself in the shoes of Boost's developers: their
aim is to spread quality C++ code to all C++ platforms.  Their aim is
broader than linux or unix.  That is why they are not using a
shell-based libtool and likely never will.

Incidentally, there is a group working on a CMake-based build system
for boost.  They are aiming to replace bjam, but it looks to be some
time before that becomes reality and likely won't address your
concerns.


> I see that there are now debian source packages for boost 1.35 and
> boost 1.36, and you're surely aware that 1.37 has been released as
> well.  Even if there were no freeze, it would clearly be impractical
> to orchestrate a boost transition once a quarter.

Indeed.  For this reason, we decided last May to upload each release
as its own source package.  Keeping multiple versions in Debian
simultaneously is our service to you, a Boost user, allowing you to
transition if and when convenient.

The situation is similar to that of automake & autoconf.  Or Qt3 and
Qt4.  Etc.  It's not ideal, but the four-times-a-year transition is
worse.


> In my opinion, the best option would be to address this with upstream
> rather than to try to roll your own system for handling boost's shared
> libraries for debian.

Indeed!  I don't expect anyone in Debian to sign up to auditing each
Boost release for ABI changes.


> Anyway, if you're interested, I would be glad to take this issue up
> with upstream, but I don't want to butt in if you're already on top of
> it.  If you're interested in some assistance navigating this issue, I
> certainly have the required background and experience with boost
> itself as well as shared libraries and debian library packaging.

I've argued SONAMES to death on boost or boost-build earlier this
year.  There certainly is dissatisfaction from the "*nix camp"
regarding the library name decorations and there is ongoing discussion
on this point in boost-build.  Some change in this regard is slated
for 1.38.  But it won't address your present concerns.

I'd encourage you to read some of the boost and/or boost-build
archives and contribute there.  I follow both lists and will join your
discussion.

My humble suggestion is that you think hard about how to decide, for
each library, whether its ABI has changed.  I strongly suspect that
simply asking Boost to inspect the code manually will get you
nowhere.

Regards,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-boost-devel/attachments/20081108/3cfcc6a9/attachment.pgp