Hi Patrick On 2021-11-30 22:43:11 -0700, Patrick Alken wrote: > All, I have uploaded a new GSL release (2.7.1) which I hope fixes the > libtool version numbers Thank you! Dirk, please go ahead with gsl 2.7.1 in unstable whenever you are ready. Cheers > > On 11/21/21 3:27 PM, Dirk Eddelbuettel wrote: > > Hi Patrick, > > > > Can you please chime in (as you did in the earlier exchanges when Sebastian > > explained to us how to set valus triplet for libtool via configure.ac) ? > > > > On 21 November 2021 at 23:00, Sebastian Ramacher wrote: > > | 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.org@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. > > > > Yes or no. We could proceed with the patch based on your suggestion. That > > would be "lighterweight" as we would not require upstream work right now. > > | As far as I am aware, the bug report lacks any mail from Patrick which > > > > He did participate earlier. Some of it may have been private mail between him > > and myself; I'd have to check. > > > > | 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. > > > > I didn't catch that aspect. Yes us moving to libgsl.so.26 by ourself now > > would make it impossible to use that soname later :-/ > > | 2. Upstream bumps the SONAME to a version higher than 26. > > > > (That would be my stylistic preference. If the next GSL is 2.8, why not take > > 28? I may be unaware of other style 'customs' here.) > > | (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? > > > > We're all ears :) > > > > Dirk > > | 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 | edd@debian.org > > | > | > > > | > | > > | > | -- > > | > | Sebastian Ramacher > > | > | x[DELETED ATTACHMENT signature.asc, application/pgp-signature] > > | > > > | > -- > > | > https://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org > > | > > > | > > | -- > > | Sebastian Ramacher > > | [DELETED ATTACHMENT signature.asc, application/pgp-signature] > > -- Sebastian Ramacher
Attachment:
signature.asc
Description: PGP signature