[Pkg-octave-devel] Lenny is out, time for work

[Thomas Weber]

Am Donnerstag, den 19.02.2009, 00:24 +0100 schrieb Rafael Laboissiere:
> Okay, in the light of the discussion, I have a proposal now:
> 
> * Thomas Weber <thomas.weber.mail at gmail.com> [2009-02-16 11:52]:
> 
> > with Lenny out of the door, we have some work ahead. I suggest getting
> > rid of the cruft first.
> > 
> > That means removal request for
> > 	octave2.1
> > 	octave2.1-forge
> > 	octaviz
> > 	octplot
> > 	inline-octave
> > 	octave-gpc
> 
> Let us request the removal octave2.1 and octave2.1-forge immediately, since
> we have already planned it for squeeze.

Done for octave2.1-forge, #516106
Once that is removed, I'll request the removal of octave2.1.


> Also, please request the removal of octave-gpc.  This package is a violation
> of the GPL, since it links a non-GPL-compatible library (GPCL) with Octave.

Done, #516111

> On the other hand, I think we should keep packages until there is a version
> of Octave in the distribution with which they work.  The inline-octave
> package falls outside this case, since it only builds against octave2.1 and
> fails with octave3.0.  So, please, ask the removal of inline-octave as well.

Done, #516112

> Packages octaviz and octplot build and work with octave3.0.  We could put
> these packages in a "feature freeze" mode and only fix the bugs in the
> Debian packaging.  

For Octaviz, okay. For octplot, I'm still in favor of removing it. If
3.2 comes out, I'm not sure octplot still provides any benefit over the
default plotting system. 

I think any second spent with octplot is better spent improving Octave's
plotting system. Octaviz (or rather VTK) provide some pretty unique
things, so I see some benefit in keeping it.

> As regards the octave packages themselves, if octave3.2 is released in the
> squeeze cycle, we could keep octave3.0 also in squeeze and remove it in
> squeeze+1, like we did with octave2.1 and lenny.  If octaviz and octplot
> only work with octave3.0 and not with octave3.2, then they will also be
> removed in squeeze+1.  In this case, we should put a warning in the
> description of these packages telling about their future removal.

I think if these packages don't work with 3.2, we shouldn't ship them in
Squeeze. I mean, by the time of Squeeze's release, there will not have
been any release for these package for 3 years.

	Thomas