Control: severity -1 serious On Sat, 16 Jan 2016 02:52:55 +0000 Mattia Rizzolo <mat...@debian.org> wrote: > control: tag -1 patch > > [ umh, you didn't CCed me, it's hard to notice reply without receving > emails ;) anyway, I just subscribed the bug, for both convenience ] > > On Thu, Jan 14, 2016 at 07:37:23AM +0100, Michael Hanke wrote: > > This dependency setting is motivated by the need for 'dicom.dic' which > > has moved a lot in the past. Currently > > it simply moved with the library soname change. > > > > > % apt-file search dicom.dic > > libdcmtk2: /usr/share/libdcmtk2/dicom.dic > > libdcmtk2v5: /usr/share/libdcmtk2/dicom.dic > > libdcmtk4v5: /usr/share/libdcmtk4/dicom.dic > > note that all these 3 packages above are not builded anymore, and holded > just by cruft in the archive. > > > libdcmtk5: /usr/share/libdcmtk5/dicom.dic > > this is the current one. And I'd expect it to change again in the > future. > > all those package were dependency of the libdcmtk-dev of the moment. > > > This is required for the tests to run. This package is often backported > > and it would be a hassle to have to modify it for each an every target. > > well, currently you are changing the build-dep of the unstable package > every so often to follow this... > > So, the problem is that you hard code that path above in d/rules, for a > package that otherwise doesn't. > For curiosity, I tried to just remove that variable declaration, and it > just works, calling `make check` seems like the program figures the > right thing alone. > > > If you have a suggestion on how to do this better, I'd be happy to > > implement it. > > I just tried a build of the current unstable package (wow â it's a long > build for a just 2MB package! :D) using my suggestion (also attached), > and it just worked. > Also, that wasy I wouldn't see any problem during backports build, > libdcmtk-dev would just pick up whatever version of libdcmtk is in that > suite. That's the normal behaviour of libraries... (even if usually lib > binaries don't ship stuff in /usr/share. And usually stuuff in > /usr/share is not in versioned directories, but I don't know how dcmtk > works) > > > At the moment I don't see how this bug is severity > > important. > > you build-depend on a package that is basically kept in the archive just > for you... (as the other 2 packages holding it are only because they > can't currently be rebuilt since they already FTBFS).
This is actually RC. Please stop build-depending on NBS packages. As Mattia said, the best option is to just build-depend on libdcmtk-dev. That will pull the current libdcmtk package (libdcmtk5 right now) which ships dicom.dic. Cheers, Emilio
