[Debian-med-packaging] Bug#826048: Bug#826048: Faulty CMake file impairs compiling against GDCM

[Gert Wollny]

Am Donnerstag, den 02.06.2016, 01:34 +0200 schrieb Peter Mattern:
> Thanks for your reply. But IMO it is missing the point.
> 
> But the problem addressed in this report is CMake returning faulty
> paths or  files that aren't available in the distribution at all
> besides they do belong to GDCM. Could you by any chance have another
> look at the paragraphs after the two  messages above?
> libvtkgdcmsharpglue.so *was installed* when cmake got invoked but
> wasn't  found as CMake didn't know the correct path. 

This is because the library is moved out of /usr/lib/<triplet> to a
gdcm specific path. It is not a library a third party is supposed to
link against. Locations for these packages are distribution specific,
because of this we cannot expect that upstream takes care of adjusting
the library path accordingly. At most they might consider in such cases
to not issue an entry in the cmake file at all, but most people use
cmake macros for library creation that would have to be adjusted for
each case and we can not expect that they think of this kind of
packaging issues that don't influence the functionality. 

> libvtkgdcmPython.so *isn't available at all* in 
> stretch besides it is basically part of GDCM. Apparently it was
> succeeded by  libvtkgdcmPython.x86_64-linux-gnu.so but
> again CMake just isn't aware of this.
Same thing here, the package creates the library without the arch
specific suffix, but because the package supports multi-arch the name
of the library must be changed (Python modules don't have an arch
specific path),  and one should also not link to this library directly
it is only relevant for the gdcm Python module. 

> And both shouldn't happen, should it?
Granted, it doesn't look nice, but it is really not that important. 

Best, 
Gert