[Debian-med-packaging] Bug#1130465: Bug#1130465: liborthancframework-dev: should the dependency on libboost-all-dev be versioned?

Paul Gevers elbrus at debian.org
Tue Mar 17 19:33:27 GMT 2026


Hi,

On 3/17/26 08:12, Sébastien Jodogne wrote:
> I have just released a new version of the liborthancframework-dev 
> package (1.12.10+dfsg-2), which notably includes the following changeset:
> 
> https://salsa.debian.org/med-team/orthanc/-/ 
> commit/43304015d951fc6701fe1329769943c10d3301c5


I had a look when the bug was closed :).

> Could you please confirm that this is what you expected? In particular, 
> I was wondering whether the ">=" should be replaced with "=".


Well, the first answer is no. But your second suggestion is less good. 
Let me explain. What I wanted you to do is think about what the 
expectations are for liborthancframework-dev. And *if* a versioned 
dependency was necessary, I was expecting something like  >= 
major-version-of-boost-during-build,  << next-major-version-of-boost~. 
Such that during the *next* boost transition, it will be lock stepping, 
but not during regular Debian revisions. If a versioned dependency is 
*not* necessary I'd like to understand what's the missing piece of the 
puzzle then.

> I also wonder why explicit versioning is required only for libboost-all- 
> dev in liborthancframework-dev, but not for the other "-dev" package 
> dependencies on C++ libraries (i.e. libdcmtk-dev, libjsoncpp-dev, and 
> libpugixml-dev).


That I don't know, I'm not very versed in c libraries. But what I'm 
guessing is that liborthancframework encodes some of the ABI (or is it 
API, I always mix those up) of boost in their own ABI and hence when 
boost transitions, liborthancframework also transitions. Now that I 
write this down, I wonder if technically liborthancframework now should 
have changed SONAME too ...

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20260317/bd8150f0/attachment.sig>


More information about the Debian-med-packaging mailing list