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

Re: VTK



Thanks Anton for CCing me. (I've worked quite a bit on the integration of VTK7 into Debian.)

> 1. In general, what were the biggest challenges you faced in packaging VTK?

In my view, the hardest thing is to get new VTK versions through the license check. That's because VTK is so huge as a package, and it's a tremendous effort to go through all files. About a year ago, we submitted a working VTK7 build for review and it took two months to get reviewed. Unfortunately, some inconsistencies were discovered which I then reported upstream [1]. Those were ironed out and we're waiting for a second review ever since [2, top of the list]. It's unclear when it will ever happen.

> Well maybe you could integrate some of patches into the upstream if you find them useful?

Indeed. Debian devs are historically lazy when it comes to feeding patches upstream, but things are changing due to the fact that it's become increasingly simple to do so (git, PRs!). Still, if you want to help out this is probably the easiest thing you can do.

And system installed VTK is still not used by ParaView and it causes some difficulties and even violation of our rules (avoid embedded copies).

This.

> 4. VTK 5 and 6 are marked as "conflicting" with each other. Why is this?

It's rather untypical in Debian to have different packages for different versions of a package. Since VTK is such a huge beast, however, dependent software package are slow to update to new VTK major versions, so in Debian you have packages depend on 5, 6, 7 etc. The fact that those versions conflict each other is only natural; after all, many of the header files will still have the same name (but different content) across different versions.

Trying to unwrap those will probably be a disruptive effort so huge that I wouldn't attempt it. It's probably easier to help all dependent software package upgrade and ditch old versions afterwards.

Cheers,
Nico

[1] https://gitlab.kitware.com/vtk/vtk/issues/17115
[2] https://ftp-master.debian.org/new.html


On Wed, Mar 21, 2018 at 10:10 PM Anton Gladky <gladk@debian.org> wrote:
Hi Kyle,

thanks for your interest on DEB-VTK-packaging! It is always pleasure to have
a responsive upstream. I was involved into the packaging on VTK 6 and
partly VTK 5.

> 1. In general, what were the biggest challenges you faced in packaging VTK?

The most difficult challenge was to use system installed versions of third-party
libraries. It is gerring better now but ideally the whole VTK should
have an opportunity to be built without embedded copies of those libs.

> 2. In particular, what was on your "wish list" of changes that you would
> have liked to see in upstream VTK that would have made packaging easier?I
> see a lot of patches in the VTK 6 packaging.

Well maybe you could integrate some of patches into the upstream if you find
them useful? Also if you join our debian science team and help to maintain
this large and important package in the collaboration with other maintainers
- it would be ideally.

We have also a ParaView which has unfortunately the embedded copy of VTK
(8 right now). And system installed VTK is still not used by ParaView
and it causes some difficulties and even violation of our rules (avoid embedded
copies).

> 3. There are existing Debian packages for VTK 5 and 6. Was any attempt made
> to package 7 or 8, even if it was never finished?

Nico and Gert are in CC. They have done a great job of packaging of VTK 7 which
is now under the review of FTP-masters. My field of interests/occupation is
changed so I do the minor support of VTK 6, waiting till it will be replaced
by a newer version.

> 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.

To be honestly - I do not remember. One can probably read about it in
the d/changelog, there were some technical difficulties. But generally
we try not to keep many versions of the same library in the archive, keeping two
of them only during the transition period. Usually the deprecated
library is being removed after all dependency are switched into the new
version.

> Thank you in advance for your help. I look forward to bringing VTK 9 to the
> Debian and Ubuntu science communities.

Thank you again for the interest and we hope that  the active upstream support
will help us to keep VTK in a better shape and to have a newer versions sooner.

Best regards

Anton

Reply to: