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 <emoll...@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
signature.asc
Description: PGP signature