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

Re: Transition needed for Octave 6.3.0?



On 8/9/21 2:36 PM, Sébastien Villemot wrote:

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


If you mean that from now on you would have a liboctave package that follows the soversion of liboctave and a libinterp package that follows the soversion of liboctinterp independently, then I think that is the correct thing to do. And in that case, if I understand the intent of the current:revision:age soversion scheme, the names of the packages could be the name of the library with the corresponding "current" revision appended and backward compatibility would be preserved if we increment the soversion numbers correctly when interfaces are added, removed, or changed. And no, I don't see a better solution than to have two different liboctave8 packages, one containing both liboctave and liboctinterp, and then one with only liboctave.

We also have liboctgui that has an soversion that may change independently of liboctave, liboctinterp, or octave itself, but we don't install header files and it is not expected to be used independently from Octave.

BTW, the 6th paragraph of the Debian policy document that says

  The SONAME and binary package name need not, and indeed
  normally should not, change if new interfaces are added
  but none are removed or changed, since this will not
  break binaries linked against the old shared library.

is not in agreement with the advice of the libtool documentation (https://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info), which says

  * If the library source code has changed at all since the
    last update, then increment revision (`c:r:a` becomes `c:r+1:a`).

  * If any interfaces have been added, removed, or changed since
    the last update, increment current, and set revision to 0.

  * If any interfaces have been added since the last public
    release, then increment age.

jwe


Reply to: