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: