Hi Dirk, On Wed, May 13, 2020 at 08:05:19 -0500, Dirk Eddelbuettel wrote:
> > Hi Julien, > > On 13 May 2020 at 14:43, Julien Cristau wrote: > | Package: libgsl25 > | Version: 2.6+dfsg-2 > | Severity: minor > | > | libgsl25 has the following relationships: > | > | Replaces: gsl, libgsl0 (<= 1.9-4), libgsl0ldbl (<= 1.16+dfsg-4) > | Conflicts: gsl, libgsl0, libgsl0ldbl > | > | However it does not actually replace or conflict with any of these > | (neither did libgsl23) as far as I can tell. Possibly since libgslcblas > | was moved to a separate package? > > Possible. Some of these may be old. Do you think I should just remove them > now? (GSL barely moves. This was an upstream release from late last summer > than lingered in experimental because I failed to trigger a transition [my > fault]). > > If we knew what a good fix was I could make a quick upload. Suggestions > welcome :) > I believe they date back to the days of libgsl.so.0, where the package was renamed but the SONAME stayed the same, a couple of times? Since the current package no longer shares filenames with those old ones I think they can just be removed. It's quite possible this still applies to libgslcblas.so.0 though, in which case the libgslcblas0 package should probably keep its own Conflicts/Replaces. > (And did you mean 'harmful' or 'harmless'? What 'harm' is being done? Do > upgrades balk? A clean install just worked in Docker...) > That was my mistake, I initially thought this is what caused the non-co-installability with libgsl23, but it's actually harmless, I retitled the bug to clarify. Sorry for any confusion. Cheers, Julien
