Re: Forge packages recompiled against Octave 5 no longer depend on liboctave7
* Sébastien Villemot <sebastien@debian.org> [2019-10-27 20:28]:
I don't know if it's technically easy to do, but I think my preferred
solution would be to have dh-octave extract the "api-vNN" string from
the oct files, and then inject the corresponding dependency (octave-
abi-NN). So, in particular, the NN in octave-abi-NN would be 53 right
now.
This is a simple-minded way of extracting the api-vNN information from
the :
$ strings src/*.oct | grep ^api-v | uniq
api-v53
However, this does not works for *.mex files.
It would be perhaps better to use mkoctfile directly for getting the
information:
$ mkoctfile --print API_VERSION
api-v53
What do you think?
Symmetrically, the octave package would automatically generate the
"Provides: octave-abi-NN" based on the "api-vNN" that it supports.
I think that, for doing this automatically, we should generate
debian/control from a source file, say debian/control.in, through string
replacement, shouldn't we?
Do you know any method for adding this Provides information dynamically
and programatically?
The advantage of this scheme is that we would not have to manually
update the @soname_version list that is currently implemented in dh-
octave.
It is also the closest technical equivalent to the former scheme, where
dpkg-shlibdeps would extract the liboctave.so.N dependency at the ELF
level to inject the corresponding dependency at the Debian package
level.
I agree with both remarks. However, I think that Mike suggested to use a
Debian-specific numbering in order to guard ourselves against future
upstream mistakes.
Rafael
Reply to: