Am Dienstag, den 11.07.2017, 14:51 +0000 schrieb Nico Schlömer:
> Thanks Gert for the explanation.
>
> Do I understand correctly that we keep vtk6 alive for backwards
> compatibility of older packages?
Well, that was my proposal (I also didn't expect that VTK8 would come
so soon, after just one point release and one bugfix release of VTK7).
> If the idea for the new vtk{7,8,...} releases is to just keep them
> coming, we could pick up an earlier idea and call the new package
> simply `vtk`. This would make skipping 7 less weird, too.
I think the idea was to make virtual packages, and yes, I fully support
that idea. However, for the name xxxx-vtk we have packages in oldstable
that refers to the vtk5 python and tcl bindings.
>
> > Then, there are quite a few packages that depend on python-vtk6,
> and currently there are some files in python-vtk* that are not co-
> > installable for two different versions of vtk,
>
> Can't we just make them conflict?
Technically yes, but if someone wants to use some software that
requires python2-vtk6 and another one that requires python3-vtkX, the
conflict would mean that they could not install both software packages
at the same time, so we should try to avoid this situation.
> > For that reason I wanted to get rid of the vtk6 python bindings,
> and go forward with VTK7, and in order to not break the reverse
> > dependencies, python2 was the choice, since it is currently the
> default version of python in Debian.
>
> I see. My idea was to keep python2 for vtk6 around, and python3
> bindings for the newer releases such that developers can choose.
That sounds reasonable.
Best,
Gert
>
> Cheers,
> Nico
>
> On Tue, Jul 11, 2017 at 4:29 PM Gert Wollny <gw.fossdev@gmail.com>
> wrote:
> > Am Dienstag, den 11.07.2017, 13:28 +0000 schrieb Nico Schlömer:
> > > > I'd say we skip VTK7 altogether, and go directly for VTK8.
> > >
> > > Don't know if this is a good idea. I know that at least FEniCS
> > > only supports VTK6 and 7, and I think not many libraries have
> > > upgraded their code for 8. (After all, it's a breaking change.)
> >
> > The major problem is with the VTK-OpenGL and OpenGL2 rendering
> > interfaces that can not be compiled in a the same time. The latter
> > requires OpenGL 3.2 and mesa doesn't support compatibility
> > profiles, - but I know that at least ginkgocadx and itksnap both
> > require an OpenGL compatibility profile, this means we will have to
> > keep two versions of VTK alive - at least until everything is
> > ported - but some packages might be dead upstream (ginkgocadx for
> > instance is kind of dead, and the changes required to make it
> > compatible with an OpenGL core profile are big, but it is of rather
> > high interest in debian-med).
> >
> > Given that currently all packages that require VTK are at vtk6,
> > IMHO it is the best to keep vtk6 for the time being, and jump right
> > to the new version, which is VTK8 for packages that make use of
> > VTK-OpenGL2. And since I don't think that we want three versions of
> > VTK in buster, my suggestion would be to skip vtk7. In the end,
> > buster is still two years away, and if we plan now to get as many
> > packages as possible to VTK8, then the extra work for a transition
> > to VTK7 would be wasted.
> >
> > > I just noticed that in your new code, my Python 3 efforts aren't
> > > included. This is what motivated me to work on VTK7, and it'd be
> > > a pity if it didn't get in.
> >
> > I understand that, but I started again from vtk6 porting all the
> > patches and first wanted it to build like it was with VTK6.
> > Then, there are quite a few packages that depend on python-vtk6,
> > and currently there are some files in python-vtk* that are not co-
> > installable for two different versions of vtk, even if one uses
> > python2 and the other one python3 (Though I have to admit that I
> > don't know whether your changes took care of this). For that reason
> > I wanted to get rid of the vtk6 python bindings, and go forward
> > with VTK7, and in order to not break the reverse dependencies,
> > python2 was the choice, since it is currently the default version
> > of python in Debian.
> >
> > Now, if we can get for instance python-vtk6 and python3-vtk8 co-
> > installable, I'd say we go for that.
> >
> > On the other hand, if you feel like we really should have a
> > VTK7+Python3 package, then just change the package names and
> > dependencies accordingly, and I will upload the vtk7 package.
> >
> > best,
> > Geert
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > Cheers,
> > > Nico
> > >
> > > On Tue, Jul 11, 2017 at 3:08 PM Gert Wollny <gw.fossdev@gmail.com
> > > > wrote:
> > > > > > I'm sorry, but the last discussion about this package was
> > > > > about two month ago
> > > > > > and nothing had happened past the version that was
> > > > > commented
> > > > >
> > > > > That's right. The discussion was moved from the mailing list
> > > > > to a private exchange between Ghislain and myself, the reason
> > > > > being (I thought) not to bother anyone with the technical
> > > > > details. I guess that was a mistake.
> > > >
> > > > The package is supposed to be group maintained, for that reason
> > > > I think it is always a good idea to keep discussions on the
> > > > list, and debian-science is not exactly high traffic.
> > > >
> > > > > Before overriding the the content I would have expected an
> > > > > email, though.
> > > >
> > > > Yes this was wrong from my side, but I did a pull before and
> > > > didn't see any change compared to May,
> > > > that's why I thought you had abandoned the effort.
> > > >
> > > > > Anyways. Let's just take it from here and see if we can get
> > > > > VTK7 out. After all, VTK8 has already been released as well.
> > > >
> > > > VTK7 would have to remain in experimental for now, because it
> > > > requires gl2ps > 1.4 currently only available from exp, and no
> > > > package depends on anything vtk7, so
> > > > I'd say we skip VTK7 altogether, and go directly for VTK8. I
> > > > would guess that most of the patches for vtk7 also apply to
> > > > vtk8, maybe the new gl2ps patch is no longer needed, because it
> > > > might have been applied upstream.
> > > >
> > > > I've created an empty vtk8 repo as
> > > > https://anonscm.debian.org/git/debian-science/packages/vtk8.git
> > > >
> > > > If you feel like it you could also rename the ITP #810254 for
> > > > vtk8 and take ownership.
> > > >
> > > > Sorry again,
> > > > Gert
> > > >
> > > >