[Pkg-octave-devel] Versiuoned packages

[Rafael Laboissiere]

Those subscribed to the pkg-octave-commit mailing list have probably
noticed the huge commit that I just did.  It concerns the changes
necessary to completely automate the generation of versioned Octave
packages (for instance octave2.1 vs. octave2.9).

Dirk had already introduced in debian/rules the basis for such
capability, but the "2.1" version number was still hard-coded in may
debian/* files, both in their contents and in their file names.  Most of
these files are debhelper-related and they were svn moved into
debian/in/PACKAGE-* files, which are processed automatically by
debian/rules to generate the appropriate debian/octave<n.m>* files.

The debian/control, which contains lots of "octave2.1" instances poses a
particular problem.  It cannot be automatically generated by
debian/rules, because it must be already present at dpkg-buildpackage
time.  I solved the problem by svn moving the file to debian/in/control.
This file is actually a template that is processed by the slice utility
(present in the package of same name).  It contains slices for both 2.1
and 2.90 versions.  This will be helpful for defining, for instance, new
build-dependencies specific to the 2.9 series (like libumfpack4 and
glpk).  After doing a fresh svn checkout, run:

    ./debian/rules debian/control

The svn directory trunk/packages/octave2.1 has been renamed to
trunk/packages/octave, to reflect the fact that it will be used for all
versions of Octave (2.1 now and 2.9 soon).  I prefer this centralized way
of doing development, but we can revert to the old scheme if something
goes weird.

I tested the new scheme with the octave2.1_2.1.68 package and it seems to
work.  Of course, this should be considered experimental and any urgent
fix must be done from the tags/packages/octave2.1/2.1.68-1 svn tag.

BTW, octave 2.1.69 has just been released...

-- 
Rafael