[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: VTK



Thank you everyone for the positive responses.

I am working through the issues with building with the system versions of the 3rd party libraries. We have a lot of custom features and bug fixes in our versions of the libraries that don't necessarily exist in their respective upstreams. Part of the packaging process for VTK 9 will be getting these non-upstreamed patches into Debian, and making sure that the latest versions that DO have our patches also get into Debian.

How do you handle copyright and licensing review? Do you look at every single file manually, or do you have a script that filters out the most common copyright headers and flags files that don't match?

We are aware of the issues with building VTK separately from ParaView. Unfortunately, this seems to be an issue inherent in the ParaView workflow. We've tried to separate them out before, and it hasn't worked well. We don't have the manpower to maintain such a separation. I think ParaView is going to be stuck with embedded VTK for a long time to come.

We are probably not going to move the modules into separate repositories and create a superbuild. However, I think it is quite feasible to separate the modules into separate Debian packages. We may even be able to write CMake scripts that semi-automate this process.

Kyle

On 03/22/2018 05:25 AM, Gert Wollny wrote:
Hello Kyle,

Am Mittwoch, den 21.03.2018, 22:10 +0100 schrieb Anton Gladky:
4. VTK 5 and 6 are marked as "conflicting" with each other. Why is
this? The libraries and headers are name-mangled to allow multiple
versions of VTK to coexist. Is there another conflict that we
didn't catch? If so, I would like to fix it.
I only started packaging vtk with version 6.3, so I don't really know
what was the reason why these two versions were marked as conflicting,
but I think it had something to do with language bindings that are
pulled in by the -dev package.

Thank you in advance for your help. I look forward to bringing VTK
9 to the Debian and Ubuntu science communities.
That is a very welcome help. I think considering that nothing in Debian
  currently depends on VTK 7 or 8 packages, I would also skip VTK8
altogether.

I think we will need to maintain vtk6 for some time more to keep the
old OpenGL interface available for software that hasn't been ported to
the new OpenGL2 rendering API (one reason being, that these packages
require a OpenGL compatibility context that is not (yet) supported by
mesa 3D).

One thing that would be nice with the vtk packages is to split the
library it into smaller functional units consisting of lib* and lib*-
dev package (e.g. IO, Rendering, ), so that one must not install all
and everything. Since you are with upstream, you know probably better
where the seams and depenedcies are that one has to take into account.

In order to make the package as a whole more managable, one might even
think about splitting the source into pieces that can be build
independendly - within the limits of inter-module dependency off course
(and use some superbuild to tie things together for those who want to
build everything like it is done now), but that's probably just a pipe
dream.

best,
Gert





Reply to: