On Sun, Oct 13, 2019 at 17:20:14 +0200, Rafael Laboissière wrote: > This will install version 0.6.2.0~ in your system. This version contains > changes in dh_octave_substvar for injecting the appropriate dependency on > the virtual package octave-abi-N, according to the version of the octave > package used in the build. This is done only for add-on packages that > provide .oct and .mex files. > > In order to make this work, we must also change the octave package to make > liboctaveN provide octave-abi-N. The general idea to provide an octave-abi-N seems like a reasonable approach to me. It is already true that Octave will only load oct files that match the ABI that a given version of Octave expects to find in them, so adding that to the packaging dependencies is good. It's probably also prudent to invent your own numbering scheme as it looks like you have done already. For reference, the mechanism that Octave uses is to compile the text value of OCTAVE_API_VERSION into each oct file, and compare it against Octave's own value at run time. If I build an oct file with Octave 4.4.1, the string "api-v52" is compiled in. If Octave 5.1.0 tries to load that oct file, it fails to compare with the new value of "api-v53" and reports an error. The upstream Octave release process always increments this string before every major release. I think we still plan to release Octave 6.1.0 early next year, and it should provide "api-v54". It's possible that the release candidates may contain the string "api-v53+". But again, I think it's probably prudent for octave-abi-N to use an independent number scheme, just in case we make a mistake upstream or something changes again. -- mike
Attachment:
signature.asc
Description: PGP signature