On 5 August 2017 at 12:35, Guillem Jover wrote:
| 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,

Yes. I have never seen it change its soname in all these years.

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

I agree. It's a bit more work, but the better fix.
 
| > 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?

Yes, it should help with that.

Thanks for the input!

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Reply via email to