[Debian-med-packaging] Bug#1130465: Bug#1134597: Please hint orthanc/1.12.11+dfsg-3 migration (force-badtest orthanc-wsi/3.3+dfsg-2)

[Adrian Bunk]

On Fri, Apr 24, 2026 at 11:27:53AM +0200, Sébastien Jodogne wrote:
> Dear Adrian,

Dear Sébastien,

> > The proper solution would be:
> > - rename liborthancframework1 to liborthancframework1.12.11, and
> > - link with the shared library instead of the static library, and
> > - make a library transition on every new orthanc version
> > 
> > With NEW processing being much faster now this should be feasible.
> 
> Thanks for these explanations.
> 
> Please could you kindly clarify: "With NEW processing being much faster now
> this should be feasible"?
> 
> I evidently understand that NEW would be the proper solution. However, my
> previous experience was that introducing a NEW package required an enormous
> amount of time, which is exactly why we decided to switch to a static
> library.

there is a new delegation for NEW processing,[1] and the NEW queue is 
now usually rather empty[2] with the median time in NEW when adding new 
binary packages being 3 hours.[3]

>...
> Couldn't an alternative solution to NEW be to make the build of the plugins
> dependent on "src:orthanc" somehow? Indeed, the build infrastructure of each
> Orthanc plugins allows CMake to rebuild the Orthanc Framework from a path
> containing the Orthanc source code.
>...

Fixing security vulnerabilities is another reason against static linking,
fixing Orthanc vulnerabilities[4] in the library would still require 
rebuilding all reverse dependencies when sttaic linking is used.

This has traditionally been the largest driver towards shared linking.

> Kind Regards,
> Sébastien-

cu
Adrian

[1] https://lists.debian.org/debian-devel-announce/2026/01/msg00008.html
[2] https://ftp-master.debian.org/new.html
[3] https://people.debian.org/~roehling/new_queue/
[4] https://security-tracker.debian.org/tracker/source-package/orthanc