Hello Paul, 2012/5/26 Paul D Turner <p...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
