On Sat, Jan 7, 2012 at 10:22 AM, Mathieu Malaterre <mathieu.malate...@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.malate...@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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
