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

Re: Packaging ITK version 5



On Monday, November 16, 2020 5:49:09 A.M. CST Gert Wollny wrote:

> > My thought is to upload to experimental first.  I don't see any
> > "experimental" branch in salsa, but maybe I can just create one?  Or
> > would it be better to  make an itk5 branch?
> 
> I'd suggest to use a new project altogether. Considering how big ITK is
> it is probably not of much help to keep the whole history of itk4 also
> in this new version. Maybe it would make sense to do a shallow clone of
> the insighttoolkit4 repo to have a starting point.

For avoidance of doubt: the source package of ITK is currently insighttoolkit4 
and the new one will be insighttoolkit5.  This convention started at the v3--
>v4 transition to allow overlapping major versions in Debian for a time.  

What I did so far is actually create 'itk5' and itk5-upstream' branches in my 
local git repo.  I had planned to keep the parallel branches as long as ITK v4 
remains in Debian, and them merge them into master/upstream.  I hadn't 
considered a new  repo altogether.  Could make sense.


> There may also be packages that need itk4 for the time being, at least
> with vtk6 there are such cases, although they relate to the switch from
> OpenGL 2.1 to 3.2, i.e. compat to core.

Yes, so I have no plan to remove ITK 4 at the moment.

 
> > Also, I recall that someone (Gert, I believe) once proposed dropping
> > the python packages for ITK 5.
> 
> Yes I did, my reasons would be that it makes the build overly long and
> large, and we do not know what people actually need. My guess is that
> people who do serious work with python itk probably compile it
> themselves anyway.

Right, and for Andreas T: the issue with "provide all interfaces" is that 
there is a *very* fine-grained set of configuration options -- e.g. do you want 
images with int components?  float?  double?  2D?  3D? 4D?  etc etc.  In 
principle, it would be nice to have everything, but it comes at a massive cost 
in build time and space; see https://bugs.debian.org/cgi-bin/bugreport.cgi?
bug=759794

Not to mention developer effort to troubleshoot all of the above.

 
> > So my thought is to drop the python package.
> 
> Agreed.
> 
> Best,
> Gert

Thanks, Gert, for all the work over the years!
-Steve

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: