Bug#654839: paraview should depend on libvtk5-dev

[Anton Gladky]

On Sat, Jan 7, 2012 at 10:22 AM, Mathieu Malaterre
<mathieu.malaterre at gmail.com> wrote:> ...
> This was my point when I requested to move VTK to deb-sci umbrella, I> believe those two packages needs the same team of maintainer, and a> very close communication.>...

I think it is a good idea to maintain VTK and Paraview under one team.
At least it can make maintaining simpler (direct commit instead of
BTS).

Anton



On Sat, Jan 7, 2012 at 10:22 AM, Mathieu Malaterre
<mathieu.malaterre at gmail.com> wrote:
> That's a totally different point. If VTK use cmake option(s) that
> ParaView/VTK does not, then we should really sync those. There is one
> pending BTW.
> This was my point when I requested to move VTK to deb-sci umbrella, I
> believe those two packages needs the same team of maintainer, and a
> very close communication.
>
>> Also VTK and Paraview are not usually releasing at the same time (I
>> think, Mathieu noticed it somewhere), so it can cause problems.
>
> That's the actual issue here. ParaView is using whatever it's VTK
> internal API is. Furthermore ParaView is released on a fixed schedule
> (6 months I believe). What this means is that
> to be able to use the VTK package for each new ParaView release, we
> would need to patch the debian/VTK with any diffs from ParaView/VTK.
> This not only require much more manpower but also could introduce some
> uneeded ABI/API change. In the past ParaView (as an application) was
> using an unstable VTK API (since the library is internal anyway). So
> unless upstream confirms this is the right way to go, I would say we
> should avoid this solution.
>
> Now the other way around, is also tricky. the debian paraview team
> would have to figure out how to build ParaView against a stable VTK.
> This means that either:
> 1. ParaView will not have new VTK feature/bugfixes,
> 2. Some good soul from paraview debian package, will figure out a way
> to backport paraview/vtk changes within paraview application code.
>
> Really it boils down to two things:
> - What is upstream position on this ? If upstream really do want to
> release  paraview on fixed schedule, with backward compatible code so
> that people can build paraview with the latest stable vtk. Then I
> would say, go for it. debian/paraview will be a
> 'paraview-with-stable-vtk' package.
> - What really is the advantage of using a system installed vtk for
> paraview in debian ? This help release team when backporting security
> fixes. So if we compare the potential of security issue in VTK code,
> the amount of work is much *much* less than what it would be to patch
> paraview and/or vtk at each new release IMHO.
>
>
>> [1] http://packages.debian.org/sid/amd64/paraview/filelist
>> [2] http://packages.debian.org/sid/amd64/libvtk5.8/filelist
>
> This is of course my point of view, and I am open to others.
>
> Thanks for your comments,
> --
> Mathieu