[Pkg-octave-devel] Packaging Octave 3.8

[Sébastien Villemot]

Le mercredi 11 décembre 2013 à 09:03 -0500, Mike Miller a écrit :
> On Wed, 11 Dec 2013 12:24:24 +0100, Sébastien Villemot wrote:
> > Le mardi 10 décembre 2013 à 23:27 +0100, Rafael Laboissiere a écrit :
> >> * Sébastien Villemot <sebastien at debian.org> [2013-12-10 12:59]:
> > 
> >>> Also, there are now 3 top-level binaries instead of one: octave, 
> >>> octave-cli and octave-gui. I am inclined to ship them in the same 
> >>> binary package (octave), but another option would be to create another 
> >>> binary package without the GUI stuff, for systems with limited 
> >>> resources.
> >>
> >> Yes, please, split the packages.  People running Octave from batches 
> >> (like I do, sometimes) will appreciate it.
> > 
> > I just realized that there is one added complexity with this approach.
> > We will have two packages providing octave: one will be just "octave"
> > like now (containing the binary which can do both GUI and command-line),
> > and "octave-cli" (containing the binary which can do only command-line).
> > It would therefore be logic to modify most reverse dependencies, like
> > the 'Forge packages, to depend on "octave | octave-cli", in order not to
> > force people to install the GUI-capable version (which would defeat the
> > purpose of splitting the packages).
> 
> I don't see the added complexity, maybe I am missing something. The
> octave package will contain /usr/bin/octave and /usr/bin/octave-cli, as
> well as all the oct-files as it does today. This is all that is needed
> to run CLI-mode octave, run m-file scripts, and install Forge packages.
> 
> The new octave-gui package will contain /usr/bin/octave-gui and depend
> on the octave package. It's an added layer instead of an alternative.

The added complexity comes from the fact that reverse dependencies will
have to be modified to depend on "octave | octave-cli" (or "octave |
octave-gui", depending on the splitting scheme that we choose). This can
be achieved first by making the relevant change to octave-pkg-dev, then
binNMUing the arch:any 'Forge packages, and making sourceful uploads for
the arch:all 'Forge packages. The binNMUs will be needed anyways for the
liboctave1->liboctave2 transitions, but the rest is a net extra cost
(and we have several dozens of arch:all packages that will need
sourceful uploads).

An alternative may be to add "Provides: octave" in the new octave-cli
(or octave-gui). I am not sure however if it is ok to provide a name
that is also the name of a real package.

Note that if we decide to do the split, I would rather create a new
octave-cli package and have "octave" ship the GUI version. This is
because starting with Octave 4.0, the GUI will be the default, so it
makes more sense to have it in "octave".

Also note that in what I pushed to git, I did not (yet?) split the
package. So the octave package ships 3 binaries: octave, octave-gui and
octave-cli.

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20131211/4df6a3bb/attachment.sig>