Bug#641542: paraview: Please use xdmf2 package rather than internal versionof xdmf

[Drew Parsons]

Control: forwarded 641542 
https://gitlab.kitware.com/vtk/vtk/-/issues/17702
Control: retitle 641542 paraview: Please use libxdmf-dev package rather 
than internal version of xdmf3

I think the general request of the bug is still valid.
Kitware should keep https://gitlab.kitware.com/xdmf/xdmf up to date, and 
fit for use by VTK,
so VTK's xdmf3 ought to have an EXTERNAL configuration option available.

People might still ask about the external xdmf library, so we might as 
well keep the bug open.
I'll update the title to xdmf3 and link to VTK upstream issue #17702 
(unifying xdmf support).

Drew


On 2026-02-04 15:54, Alastair McKinstry wrote:
> Hi Drew
> 
> Sorry on the delay in replying, I got hit with a VPN bug and couldn't
> reach my email from my current laptop.
> 
> I think reframe it. Your reading of the problem is correct, I think.
> I packaged xdmf way-back-when and moved it directly to xdmf3 thinking
> it would (should) work like any other library, with transitions. Not
> expecting an application to use both xdmf2 and xdmf3.
> 
> I've no plans (or time ) to package VisIt, so don't see the need.
> We could either leave it as wishlist, or close
> 
> Regards
> Alastair
> 
> On 01/02/2026, 17:49, "Drew Parsons" <dparsons at debian.org> wrote:
> Package: paraview
> Followup-For: Bug #641542
> X-Debbugs-Cc: Alastair McKinstry <mckinstry at debian.org>
> Control: reassign -1 src:vtk9 9.5.2+dfsg3-1
> 
> Hi Alastair, do you think Bug#641542 is still live, or should we close
> 
> it now, or reframe it?
> 
> There's a couple of points on the current state of it.
> 
> Firstly the vendored xdmf code was in VTK not paraview as such.
> paraview had been vendering its own VTK code due to incompatibility
> with libvtk9-dev, but that is now resolved with paraview 6 / vtk9 9.5.
> 
> The xdmf code is still in VTK, so I'm moving this bug from paraview
> to vtk9.
> 
> Next, vtk9 does vendor both xdmf2 and xdmf3 in ThirdParty.
> But debian's separate libxdmf-dev is xdmf3 not xdmf2 (if I understood
> correctly).
> 
> vtk9 does allow to build with some external libraries. We're doing
> that with eigen, expat, zlib and others. vtk allows for this with a
> EXTERNAL option in the CMakeLists.txt for the ThirdParty component
> dir.
> 
> But in the case of both xdmf2 and xdmf3, vtk is using
> vtk_module_third_party_internal, with no EXTERNAL.
> 
> I tried briefly to patch ThirdParty/xdmf3 to use the external
> libxdmf-dev, but VTK didn't find the external library cleanly. It can
> probably be done but it will need some effort. Is it worth the effort?
> 
> 
> But even if vtk9 is patched to use external libxdmf-dev, that's xdmf3
> not xdmf2 (correct me if I'm wrong about that).
> 
> Kitware has taken responsibility for ongoing xdmf code development at
> https://gitlab.kitware.com/xdmf/xdmf
> But they haven't (yet) facilitated enabling VTK to use xdmf as an
> external
> xdmf library. Instead, they've just been updating their vendored copy
> from time to time when needed, most recently last week with
> https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12864
> 
> With respect to VisIt, paraview 6 uses Utilities/VisItBridge to access
> 
> VisIt, rather than providing VisIt directly. As far as I can see VTK
> doesn't contain VisIt either. So there's currently no second copy of
> xdmf2 as such. Debian currently isn't packaging VisIt itself, but I
> can't see a direct copy of xdmf (either version) in the VisIt source
> at
> https://github.com/visit-dav/visit/tree/develop/src/third_party_builtin
> 
> src/CMake/FindXdmf.cmake seems to imply they would get xdmf from vtk
> (vtklibxml2)