Re: [Pkg-octave-devel] Packaging Octave 3.8

[Rafael Laboissiere <rafael@laboissiere.net>]

* Sébastien Villemot <sebastien@debian.org> [2014-01-02 21:51]:
> Le jeudi 02 janvier 2014 à 21:39 +0100, Rafael Laboissiere a écrit :
> > * Sébastien Villemot <sebastien@debian.org> [2014-01-02 20:04]:
> >
> > [snip]
> >
> > I took a quick look at the non-forge packages that depend on liboctave1, 
> > which are:
> >
> >    octave-vlfeat
> >    sdpam
> >    octave-psychtoolbox-3
> >    octave-plplot
> >    octave-pfstools
> >    octave-nlopt
> >    libsbml5-octave
> >    octave-gdf
> >    octave-lhapdf
> >    octave-gmt
> >    octave-biosig
> >    octave-sundials
> >
> > [snip]
>
> But this was not my point. I am thinking about partial upgrades, i.e. a 
> situation where the user upgrades octave but not some package depending 
> on it (and that package will therefore still be using liboctave1). And, 
> if partial upgrades do not work, then it is our duty to avoid them by 
> adding the corresponding Breaks.

I guess that all packages that I listed above will be broken (or 
half-broken) after upgrading to octave_3.8.0, since they need the 
interpreter and the *.oct and *.mex files included in them will not work. 
I did some tests and got segmentation faults.  I did not test all 
packages, though,

The hypothetical case that you mention above would be a package 
containing a executable that is linked against liboctave1 and does not 
need the interpreter to be run.

I think that your proposal "Breaks: liboctave1" is probably the best 
solution.

Rafael