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

[Peter Mattern]

Thanks for your reply. But IMO it is missing the point.

Maybe we should first reconsider the workflow that takes place.
An application, here Ginkgo CADx, is sort of querying CMake like "Could you 
please tell
me which library is providing feature foo?" and CMake replies "Sure. It's 
library
/usr/lib/x86_64-linux-gnu/libFoo.so.".

Due to the sophisticated packaging in Debian it may very well happen that 
libFoo.so isn't
accessible right when cmake gets invoked simply as the package providing 
the library isn't
installed.
This is what I had in mind writing the "side note" in the initial posting 
and what you
were referring to in your reply.

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. 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.
And both shouldn't happen, should it?