conflicts between VTK/XDMF and libloki

Gert Wollny gw.fossdev at gmail.com
Tue Dec 6 15:59:35 UTC 2016


Hello Alastair, 



Am Montag, den 05.12.2016, 13:56 +0000 schrieb Alastair McKinstry:
> I'm the maintainer of xdmf, which I packaged to work with VisIT and
> related code (in particular CDAT, which  uses VISIT).
> 
> I originally packaged xdmf, recently moving up to xdmf3 as required
> by VTK 7+. (I plan to submit a patch to VTK later to use the external
> xdmf rather than its internal copy.)


The current version of VTK in Debian is 6.3 (which is EOL upstream),
and the internal xdmf version there does not contain a copy of libloki,
so there is no problem with libvtk6-dev in stretch. 

> However it appears that xdmf3 ships its own version of libloki, which
> conflicts, especially /usr/include/loki/*
> 
> The xdmf version is similar except it applies its own patch to
> /usr/include/loki/Visitor.h, where it passes Xdmf shared pointers,
> thus breaking the API/ABI:
> 
> (Compare
> https://sources.debian.net/src/libloki/0.1.7-3/include/loki/Visitor.h
> /
> and
> https://sources.debian.net/src/xdmf/3.0%2Bgit20160803-1/core/loki/Vis
> itor.h/
> )


> I'm at a loss what to do at this point - can the libloki and VTK
> packagers give an opinion?
One of libloki-dev and libxdmf-dev should declare a conflict with th
eother.

Luckily xmdf doesn't ship the loki-library (I assume for that reason it
is smaller), so that there are no conflicts when installing the
libraries. 

Of course I would also suggest to file a bug against xdmf upstream and
ask them to change the file name, namespace, and include guards of
their embedded loki version to avoid conflicts with the original loki
library. 

hope that helps, 
Gert 





More information about the debian-science-maintainers mailing list