[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: