[Debian-med-packaging] Bug#1098944: libdcmtk19: strict dependency on dcmtk-data makes smooth transitions impossible

Étienne Mollier emollier at debian.org
Wed Feb 26 19:25:05 GMT 2025


Hi Emilio, Hi Mathieu,

Emilio Pozuelo Monfort, on 2025-02-26:
> The shared library package has gained a strict dependency on dcmtk-data,
> such as dcmtk-data (= 3.6.9-4). This makes it impossible to install two
> libdcmtk, e.g. libdcmtk18 and libdcmtk19, because they depend on different
> versions of dcmtk-data, which is not possible. This makes transitions harder,
> as well as calculating dist-upgrades.

Ouch, that seems to explain why the migration tool remained
blocked on the former libdcmtk18 package while looking for
Excuses.  Thanks for the notice!

> I see that dcmtk-data contains files in versioned directories, so perhaps
> the package could be moved into libdcmtk19. Another solution is to version
> dcmtk-data. Or if those files aren't really changing that much, they could
> be moved to a non-versioned path, and loose the dependency a bit, e.g.
> dcmtk-data (>= ${source:Version}).

Upon examination of data files, I see that some of them differ
in such a way that some data are appearing, and some other are
"retired" (using the vernacular of the dicom data dictionary
files).  Perhaps there is enough logic allowing the library to
work with mismatched dictionaries upon the time of the system
upgrade, although I wouldn't bet too much on it.  And there are
differences in the binary files which I haven't quantified.  But
mismatched dcmtk-data and library works, then I would lean on
relaxing the version dependency.

If on the other hand data mismatching the library is a problem,
then I would tend to go for injecting the data in the library
package, as it seems to me the easiest solution.  It would be
necessary to have the data set to remain in a versionned
directory to preserve coinstallation of both library versions
though.

Versionning the dcmtk-data package would involve a round trip
through NEW and wouldn't remove the need to ensure there are no
file conflicts.  In any case, in a context of upgrading from
bookworm to trixie, the dcmtk-data package didn't exist yet, so
we are already achieving coinstallability between libdcmtk17 and
libdcmtk19.  Otherwise said, we're not caught by time yet.

Mathieu, what do you think?

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <emollier at debian.org>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/7, please excuse my verbosity
   `-    on air: WiZRD - Fire & Flames
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20250226/e5e6c8ea/attachment.sig>


More information about the Debian-med-packaging mailing list