[Pkg-octave-devel] Packaging Octave 3.8

[Rafael Laboissiere]

* Sébastien Villemot <sebastien at debian.org> [2014-01-02 21:51]:
>
> Le jeudi 02 janvier 2014 à 21:39 +0100, Rafael Laboissiere a écrit :
>> * Sébastien Villemot <sebastien at 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