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

Re: Forge packages recompiled against Octave 5 no longer depend on liboctave7



Le dimanche 27 octobre 2019 à 19:16 +0100, Rafael Laboissière a écrit :
> * Mike Miller <
> mtmiller@debian.org
> > [2019-10-25 16:58]:
> 
> > 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.
> 
> Thank you for this detailed explanation, Mike!
> 
> i think I will go ahead and release the version of dh-octave that 
> implements the octave-abi-N dependency.
> Just a further question: should I 
> make the N in octave-abi-N the same as the N in liboctaveN?

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.

Symmetrically, the octave package would automatically generate the
"Provides: octave-abi-NN" based on the "api-vNN" that it supports.

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.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: