Re: [Pkg-octave-devel] Status of packages before etch freeze
Hi,
Am Sonntag, den 22.10.2006, 13:15 +0200 schrieb Rafael Laboissiere:
> First, the 2.9 branch of Octave will soon become the de facto stable version
> [2]. When this will happen, the Debian packages will become immediately
> outdated because the virtual "octave" package depends on octave2.1 and not
> on octave2.9. We could fix this with an new upload of the octave package. I
> think we still have room for doing it before etch freezes. However, this
> would also the other packages (inline-octave, octaviz, octplot, and
> octave-epstk) would need to be rebuilt against octave2.9.
- epstk already has a dependency on 2.9 or 2.1
- inline-octave might work, but I don't know
- octplot's author likes to stay with 2.1 for the time (this might
change as soon as Octave 3.0 is the new recommended version)
- octaviz should probably get an overhaul of its build system, as
suggested by you, before even trying to switch to a newer Octave
version) [1]
> Doing all this before the freeze is quite tight, so I would like to
> hear the opinion of the DOG members.
I consider most of this post-etch. We are facing the usual problem of
scientific software:
http://lists.debian.org/debian-science/2006/07/msg00031.html
=====================================================================
- People when using packages wish them to closely follow upstream
(like a package build daily from the cvs or equivalent).
- But in the same time they wish them for the stable distribution.
They want it globally stable but very unstable for the specific
software they are tracking for their day to day work. So this mixes
quick packaging procedures and backport needs.
=====================================================================
At one point, we must simply draw a line.
> Finally, we are doing quite well as regards the open bugs reports. Most of
> them are upstream problems and have been appropriately tagged/forwarded.
> Only Bug#367165 (octave2.1: please put runtime libraries in /usr/lib, not
> /usr/lib/octave-VERSION) is not yet tagged or forwarded because we do not
> know really how to cope with it.
I think the best solution to this (the one with the most work <sigh>)
would be a switch to automake for Octave (it currently uses autoconf but
hand-written Makefile.ins) and then using libtool for Octaves'
libraries.
I remember reading a discussion about automake on Octave's list (around
1999?) and I think John was open to an implementation but didn't have
the time to do it.
[1] Semi-related note: upstream accepted most of our patches for
building Octaviz against VTK 5.
Thomas
Reply to: