Le dimanche 08 août 2021 à 00:04 -0400, John W. Eaton a écrit : > On 8/7/21 11:22 AM, Rafael Laboissière wrote: > > * Sébastien Villemot <sebastien@debian.org> [2021-08-07 17:17]: > > > > > Since bullseye is scheduled for release on 2021-08-14, we will soon be > > > able to upload Octave 6.3.0 to unstable. > > > > > > However, the release notes say: > > > > > > This bug fix release breaks ABI compatibility with Octave 6.2.0. > > > Re-build binaries (like .oct or .mex files) when updating to this > > > version. > > > > > In any case, we should try to understand what is the exact nature of > > > the ABI breakage. I could not find useful information in the mercurial > > > log. Maybe we should contact the Octave developers (if some of them > > > are reading this, please follow up!). > > > > As far as I know, there were no changes in interfaces in liboctave that > required changing the "current" version of the library as described here: > > > > http://hg.savannah.gnu.org/hgweb/octave/file/3e5e88d9c85f/etc/HACKING.md#l337 > > The interface changes in liboctinterp that forced the change in the > current version for that library were discussed here: > > https://octave.discourse.group/t/more-frequent-minor-releases/1127/16 > > The bug report that prompted the interface changes is here: > > https://savannah.gnu.org/bugs/?60237 > > Comment #12 has links to the patches that changed interfaces. Thanks John for this information. I see that the soversion of liboctinterp has been bumped, which is all good. Now, we have to decide what to do on the Debian side, given that the liboctave8 package currently contains both liboctave and liboctinterp. They had been lumped together on the (implicit) assumption that they would always have the same soversion. This is allowed by Debian policy, section 8.1, 4th paragraph¹. But we are no longer in this configuration: in Octave 6.3.0, liboctave has soversion 8, while liboctinterp has soversion 9. Even though we could technically keep the libraries bundled together (renaming liboctave8 to liboctave8b), this would probably no longer be in line with the Debian policy. So I think we should now ship liboctinterp in its own package (called liboctinterp9 at first). Note that we will now have a problem with liboctave8 on upgrades, because it will no longer contain liboctinterp8. This would break packages that depend on liboctave8 in some partial upgrades configurations (e.g. upgrading liboctave8 but not the main octave package). I think that the right technical solution is to rename liboctave8 to liboctave8b when we drop liboctinterp from it (and when Octave 7 is released, we would resume the normal naming scheme). Or do you see a better solution? ¹ https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part