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]