Bug#911793: Control: reassign -1 src:gdcm 2.8.7-2

[Gert Wollny]

Hello, 

Am Freitag, den 23.11.2018, 16:30 +0100 schrieb Emmanuel Promayon:
> Dear all
> 
> Thank to Paul for your answers about the autoremoval and explanation 
> about the ABI problem. It seems that Adrian Bunk's triage message in 
> 909120 (added blocking bug(s) of 909120: 911793) did push the 
> autoremoval for another month (thanks to Adrian as well, as that's 
> exactly what is happening).
> 
> Thank you to Mattia for finding the ABI problem and to Matthieu for
> his comments.
> 
> Thank you to Gert for the explanation about vtk7 (by the way do you
> have any idea about the possible future introduction of vtk8 or
> vtk9?).
The problem is that I moved to a different work which is rather
unrelated to using VTK, so my personal interest there is quite limited.
There was also some discussion of actually using paraview as a vehicle
to also bring in the VTK libraries, because paraview has them bundled
and it seems to be difficult to unbundle them.   


> You are right about camitk-imp and camitk-config: they are not
> linked 
> with gdcm. When camitk-imp or camitk-config are run they load some 
> plugins (e.g. the dicom plugin) that itself is linked with gdcm.
> Running ldd on one of the pluging get the similar missing vtk
> symbols and so. So I suppose the problem is in vtk7
I found the problem with the missing libraries, it was indeed something
I messed up when I removed the QT dependency on armhf/armel. 

> 
>  From what I can understand (sorry in advance for any approximation
> or  stating the obvious):
> 1) gdcm 2.8.7-2 moved to python3 (probably because a move from
> python2 to python3 was required) which I think triggered the choice
> of moving from vtk6 to vtk7 (which probably made more sense, as I
> presume vtk6 is  also on its way out of buster).
AFAIK vtk6 doesn't support python3 at all, and the general idea is to
at least minimize the use of vtk6, only provide the libraries, but let
vtk7+ provide the language bindings.  

It will not be possible to remove it completely because of the switch
to OpenGL 3.2 in vtk7 which breaks a number of reverse dependecies
(ginkgocadx and maybe also itksnap).

> 2) When gdcm 2.8.7-2 arrived in sid, it generated a SegFaults
> during camitk 4.1.2-1 as camitk 4.1.2-1 was still based on vtk6, and
> loading  any camitk executable meant that both vtk6 and vtk7 were
> loaded in memory.
This is where I messed up a bit, because I didn't expect that vtkgdcm
would export symbols from vtk, and I didn't check the reverse
dependencies because I was only focused on python3 (and there
inveselius), but this is independend from camitk pulling in two
versions of vtkm, even if vtkgdcm would not export VTK symbols then
this would still have been a problem.

> 3) camitk 4.1.2-2 introduced a patch so that it only depends on vtk7 
> (and like gdcm 2.8.7 without changing the upstream source version).
> 4) gdcm 2.8.7-5 then fixed the double dependency to vtk6 and vtk7
> but camitk 4.1.2-2 was not rebuilt against it, therefore generating
> the initial error that triggered bug #911793
> 5) vtk7 (which was updated in the meantime) seems to have now some 
> missing libraries and as hdf5 is broken as well camitk 4.1.2-2 can
> not be rebuilt yet
I'm noit so sure about the inbetween parts, but the last step is
correct. I just have to check the pytjon problem, and then I should be
able to upload a new vtk7 version. 

> 
> Let me know if there is anything I can do to help.
> 
> On a side discussion:
> Does the fact that I moved the dependency of camitk from vtk6 in
> 4.1.2-1  to vtk7 in 4.1.2-2 might generate another ABI break? 
AFAICS camitk is a leaf package, so there shouldn't be any ABI break
possible.

> If this is the  case, I will take any advice regarding how to specify
> this properly! I will also welcome any information/documentation
> about how to track the symbol.
I tried to tdo this once, but with C++ libraries and templates it was
not quite streightforward, so I gave up on it. 

Best, 
Gert