Bug#674633: libogre-dev: Uses default versions of libboost-*-dev packages

[Manuel A. Fernandez Montecelo]

Hello Paul,

2012/5/26 Paul D Turner <paul at cegui.org.uk>:
> Package: libogre-dev
> Version: 1.7.4-5
> Severity: important
>
> Dear Maintainer,
>
> Rather than using default versions, I believe the package should depend
> on whichever specific version of the libboost-date-time-dev and
> libboost-thread-dev packages were used to build the Ogre binary libs.
>
> By not having the specific version as a dependency it becomes very easy
> for the libboost-*-dev packages to be upgraded or held-back

Talking in general about Debian packages, or even shared-linked
libraries as a concept, that's the very much the intended outcome,
yes.

This has several benefits for Debian, its maintainers and users as a whole:

- that people don't have installed 10 versions of the same library,
saving space, memory, bandwidth...

- that maintainers of those libraries (boost in this case) don't have
to take care of too many versions of their package being in the
archive at the same time, each one with its own set of bugs and quirks

- that security updates propagate quickly

- that transitions from one version of the library to another don't
always take ages, and that developers maintaining those libraries
don't have to take the burden to modify those of the packages
depending on them (which is hundreds in the case of libpng, libjpeg,
boost...) which are unmaintained, when they want to remove an old
version of the library from the distribution.

Probably you know some or all of this things already, but just to set
the frame for the subsequent comments.


> [...] and thus
> become out of sync with the version used to build the binary Ogre
> libraries - this can result in issues when running code built against
> Ogre on a system where such a mis-match of boost versions has occurred.

I am not sure that I understand this part.

$ apt-cache show libogre-dev | grep "^Depends" | tr , '\n'
Depends: libogre-1.7.4 (= 1.7.4-5)
 libboost-date-time-dev
 libboost-thread-dev
 libfreeimage-dev
 ...

$ apt-cache show libogre-1.7.4 | grep "^Depends" | tr , '\n'
Depends: libboost-thread1.49.0 (>= 1.49.0-1)
 libc6 (>= 2.4)
 ...

So libogre-dev depends exactly on "libogre-1.7.4 (= 1.7.4-5)", and
this one in turns on "libboost-thread1.49.0 (>= 1.49.0-1)".  Indeed,
the dependency on boot is already "qualified" with a SOVERSIO/SONAME.

In theory, shared libraries should be backwards compatible (ABI) or
mangle SONAME and SOVERSION accordingly, so the linker (and associated
Debian tools) know what to do when generating the package
dependencies.  There are some more advanced mechanisms (versioning
with symbols exported by the libraries), but OGRE is not using that at
the moment.

Apart from that, it's not only OGRE which depends on un-versioned
libboost-*dev, but the same happens with the ~100 packages depending
on libboost-thread* in unstable -- only a few depend on 1.46
explicitly (and even in these cases, it might be a "mistake"):

$ apt-cache rdepends libboost-thread1.46.1 | grep "^  " | wc -l
5
$ apt-cache rdepends libboost-thread1.49 | grep "^  " | wc -l
99

There are a few -dev libraries depending on libboost-thread-dev:

$ apt-cache rdepends libboost-thread-dev | grep "^  "
  libwt-dev
  libplayerc++3.0-dev
  libopenwalnut1-dev
  libogre-dev
  libmapnik2-dev
  libzeep-dev
  libtorrent-rasterbar-dev
  drizzle-plugin-dev
  libdolfin1.0-dev
  libcgal-dev
  libboost-all-dev

And there are actually no packages in the whole archive depending on
specific (versioned) versions of libboost-thread*-dev, except boost
packages of the same version:

$ apt-cache rdepends libboost-thread1.46-dev | grep "^  "
  libboost-thread1.49-dev
  libboost1.46-dev
  libboost1.46-all-dev
$ apt-cache rdepends libboost-thread1.49-dev | grep "^  "
  libboost1.49-dev
  libboost1.49-all-dev
  libboost-thread-dev


> The issues can occur because Ogre exposes its use of boost to client
> code, so a situation can arise where client code compiles in one version
> of boost template code whereas the binary Ogre contains different and
> possibly incompatible code.
>
> Given this situation, when the binary ogre and client code have affected
> objects passed between them, bad things happen.

So with my argumentation above, I wanted to make clear that the
decision to depend on un-versioned boost -dev libraries is not
uncommon within Debian -- on the contrary, OGRE would be a clear
exception.  So if we go down this route, I want to make sure that it's
really needed.

Now, I really don't understand very well what's the problem, or why
OGRE should really be different from all other packages depending on
un-versioned libboost*-dev packages.

If one compiles a template in C++ to work with some of your
classes/data types, the template code for classes A and B is different
anyway (IIRC), even if you use the same version of a library (there
are two copies of the code in different memory locations), so there
should be no conflict.

Do you have an specific example that explains the issue more clearly?

Regards.