On 2021-11-09 12:54:44 -0600, Dirk Eddelbuettel wrote:
> 
> On 8 November 2021 at 22:14, Sebastian Ramacher wrote:
> | Control: tags -1 moreinfo
> | Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-gsl.html
> | 
> | On 2021-10-31 14:29:40 -0500, Dirk Eddelbuettel wrote:
> | > 
> | > Package: release.debian.org
> | > Severity: normal
> | > User: release.debian....@packages.debian.org
> | > Usertags: transition
> | > 
> | > GNU GSL 2.7 was release a few months ago, and we now realised (in the
> | > discussion of #993324 which also included upstream) that the upstream 
> libtool
> | > instruction were in error by _not_ leading to a new sonumber. This was
> | > corrected in (source package) gsl upload 2.7-3 to experimental, which 
> built
> | > well.
> | 
> | What's the status of the fix upstream? Was there any progress? Otherwise
> | we're gonna repeat that with the next upstream release.
> 
> Those are two distinct issues.  Upstream, I think we all agreed in the thread
> also recorded in the BTS, made an omission in this release where a new soname
> was needed, but wasn't given. This happens.  So now we need a new soname
> __because the ABI/API changed__.

Yes, the ABI changed and we need a new SONAME. This would ideally be
done upstream, though. Even better would be a new release with that change.

As far as I am aware, the bug report lacks any mail from Patrick which
would currently mean that we'd have a Debian-specific SONAME. If we go
ahead with that, we will end up in on of the following cases:

1.  Upstream bumps the SONAME as we discussed it in the bug report.
    Given the changes in [1], the next release of gsl would then have a
    SONAME of libgsl.so.26, but with an incompatible ABI compared to what we
    would have in the archive.

2.  Upstream bumps the SONAME to a version higher than 26.

(3. Upstream simply ignores the issue)

If 1. happens, we'd be unable to sync up with upstream's SONAME (there's
a good reason why we tend to avoid Debian-specific SONAMEs). 

Patrick, what are your planes?

Best
Sebastian

[1] 
https://git.savannah.gnu.org/cgit/gsl.git/commit/?id=191bf01a38e590dd0df8aa571accbbd331bfee07

> 
> That has happened before, and that is why we had transitions in the past.



> 
> But not all previous releases had soname changes. I have maintained GSL here
> for about 20 years and I think this is about the third transition. I would
> call that defensible.
> 
> The release team does of course have a broader view, and I am always keen to
> hear your thoughts.
> 
> Cheers, Dirk
> 
> | Cheers
> | 
> | > 
> | > I would like to ask for a formal transition. As we saw with failing tests 
> in
> | > dependent packages, binNMUs will not work for all package (but possibly
> | > "most"). 
> | > 
> | > Tentative ben file below.
> | > 
> | > 
> -----------------------------------------------------------------------------
> | > title = "gsl 2.7 transition";
> | > is_affected = .depends ~ /libgsl-dev/;
> | > is_good = .depends ~ "libgsl26";
> | > is_bad = .depends ~ "libgsl25";
> | > 
> -----------------------------------------------------------------------------
> | > 
> | > Let me know if I can help otherwise.
> | > 
> | > Cheers, Dirk
> | > 
> | > 
> | > -- 
> | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> | > 
> | 
> | -- 
> | Sebastian Ramacher
> | x[DELETED ATTACHMENT signature.asc, application/pgp-signature]
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 

-- 
Sebastian Ramacher

Attachment: signature.asc
Description: PGP signature

Reply via email to