Hi!
On Fri, 2017-08-04 at 23:10:49 -0500, Dirk Eddelbuettel wrote:
> On 5 August 2017 at 00:04, Alf Gaida wrote:
> | like the subject says libgsl lacks some breaks and replaces, that breaks
> the upgrade path:
> | The following should fix that
> |
> | diff --git a/debian/control b/debian/control
> | index 5e12819..486169d 100644
> | --- a/debian/control
> | +++ b/debian/control
> | @@ -12,8 +12,9 @@ Architecture: any
> | Multi-Arch: same
> | Pre-Depends: ${misc:Pre-Depends}
> | Depends: ${shlibs:Depends}, ${misc:Depends}
> | +Breaks: libgsl2
> | Conflicts: gsl, libgsl0, libgsl0ldbl
> | -Replaces: gsl, libgsl0 (<= 1.9-4), libgsl0ldbl (<= 1.16+dfsg-4)
> | +Replaces: gsl, libgsl0 (<= 1.9-4), libgsl0ldbl (<= 1.16+dfsg-4), libgsl2
> | Suggests: gsl-ref-psdoc | gsl-doc-pdf | gsl-doc-info | gsl-ref-html
> | Description: GNU Scientific Library (GSL) -- library package
> | The GNU Scientific Library (GSL) is a collection of routines for
>
> Thanks for that.
>
> One possibly alternative would be to put libgslcblas.so.0.0.0 into its own
> libgslcblas depend on it as this library has no soname.
Strictly speaking, libgslcblas does have a SONAME:
$ objdump -p /usr/lib/x86_64-linux-gnu/libgslcblas.so.0 | grep SONAME
SONAME libgslcblas.so.0
which means to me that it should guarantee some ABI stability,
otherwise this library should become a private library by using RPATH,
or be folded into the main libgsl library?
And IMO, splitting this library appears as the only correct solution
here, because:
- Both shared libraries have different SONAMEs that's (I'm assuming)
why you've had to keep adding Replaces against the old packages when
bumping the SONAME for the main library.
- This causes transition problems, as both old and new main library
packages cannot be installed at the same time, even though by
themselves alone there would be no filesystem conflicts. Which in
turn means we cannot have a mix of packages linking against the
old and new libraries, or in worse conditions a mix of a new -dev
using the new librs with some other packages using the old libs.
- If (but I'm not sure if that's possible) one can link only against
the libgslcblas library, that would cause breakage in case the
SONAME gets bumped as as the package is not keyed on that, and
programs linked against the old SONAME would stop working.
> But it is probably
> easier to go with 'Breaks: ' as you suggest.
I'd consider that the wrong fix TBH.
> The thing that is unpleasant is that we probably need to keep adding the old
> soname libraries to debian/control as this progresses.
Not anymore after the libraries have been split. Or perhaps I don't
understand your concern?
Thanks,
Guillem
