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
> 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
If you feel like it you could also rename the ITP #810254 for vtk8 and take ownership.
Sorry again,
Gert