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

[Jay Berkenbilt]

Debian boost packagers --

As a fellow library packager, I thought I'd bring up an issue I know
you must be all too aware of to see whether anyone is considering
addressing it with upstream.

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.  This means that every application that links with any boost
library must be relinked with every new boost release even if that
application uses a library that was not changed.  Now that boost is
doing quarterly releases, this is a big deal.  For example, I use the
boost regex library a lot in my code, and that has not changed in a
few releases.  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.  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.

I understand that boost upstream is using a different build system
(bjam) that works on Windows, Mac, and other platforms for which
libtool may not necessarily work, and perhaps libtool isn't even
integrated into bjam.  Their existing library name mangling scheme
also makes it easier to support multiple simultaneous boost versions
and prevents them from having to deal with the differences in soname
conventions on different platforms (which is a lot of what libtool is
useful for), but it still seems to me like the wrong solution for a
distribution like debian.  It seems like taking the easy way out while
causing a lot of trouble for packagers.

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.  Also, it's against
general debian policy to have more than one version of a library in
the system at a time, and having more than two versions is strongly
discouraged.  I wouldn't be surprised if ftp masters rejected an
attempt to upload a boost1.37 package.

Ideally, there should be just one "boost" source package, and it
should create separate binary packages for each library (as it does
now) named with the library's soname in it.  When a new version of
boost is released, the soname would only be bumped for libraries that
have non-binary-compatible changes, as is customary with shared
libraries.  This way, only those packages that depend on the specific
libraries that changed would have to be rebuilt.

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.

Have any of you given consideration to this issue or brought it up
with upstream?  I can't imagine that debian is the only distribution
that is inconvenienced by this.  I have sometimes made the decision to
not use boost for this reason.  For example, my qpdf software uses
PCRE instead of the superior boost_regex library because I don't want
to get stuck being dependent on boost in debian and having to be part
of every boost transition.

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 can also post this as a bug in the BTS rather than just sending it
to you in email.

-- 
Jay Berkenbilt <qjb at debian.org>