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

Re: Transition needed for Octave 6.3.0?



Le lundi 09 août 2021 à 15:32 -0400, John W. Eaton a écrit :
> 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.

Ok, thanks.

> 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.

Currently, we don’t ship liboctgui in a separate package, so we don’t
have to track the soversion of that library.

> 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.

Actually, there is no contradiction between Debian policy and libtool
documentation. The soversion generated by libtool is not equal to the
“current” version; it is equal to “current” minus “age”. You can verify
for yourself that, if the rules given in the libtool documentation are
followed, the soversion generated by libtool will change if and only if
an interface is changed or removed (which correspond to the case when
the Debian package name should be changed).

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


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


Reply to: