Hi all, Le lundi 09 août 2021 à 20:36 +0200, Sébastien Villemot a écrit : > 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? I changed my mind and I now have a (possibly) better plan. Instead of creating another separate shared library package for liboctinterp, the idea would rather be to drop the liboctave package and to turn the liboctave and liboctinterp shared libraries into private ones, as is actually done by upstream (incidentally, we could therefore the install_libraries_publically.patch that we have carried over for a long time). Making those libraries private was also the recommendation of a Release Team member.¹ Previously it was necessary to have these libraries installed in a public location, because .oct files were linked against them (and dpkg- shlibdeps would complain if they were kept private). But since Octave 5, .oct files no longer link against liboctave and liboctinterp.² So we should now be able to make those libraries private. I have verified on a specific Forge package (octave-struct) that it works as expected. The only exception is octave-nlopt, which explicitly links against liboctave8 (because it does not use mkoctfile and rather has its own build system). However I have a working patch that fixes the issue. In parallel, if we go down that road, then I would suggest to rename liboctave-dev to octave-dev (since there will no longer be a liboctave* package). Of course, we would implement a transitional package for one or two release cycles. What do you think? ¹ https://lists.debian.org/debian-octave/2018/10/msg00001.html ² https://lists.debian.org/debian-octave/2019/10/msg00002.html -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part