On 14 October 2021 at 23:20, Sebastian Ramacher wrote: | On 2021-10-14 15:52:03 -0500, Dirk Eddelbuettel wrote: | > | > Hi Sebastian, | > | > On 14 October 2021 at 22:46, Sebastian Ramacher wrote: | > | Hi Dirk | > | | > | On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote: | > | > | > | > On 30 August 2021 at 23:42, Niko Tyni wrote: | > | > | Package: libgsl25 | > | > | Version: 2.7+dfsg-2 | > | > | Control: affects -1 libmath-gsl-perl | > | > | Severity: serious | > | > | | > | > | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest regressions: | > | > | | > | > | not ok 7 - use Math::GSL::Matrix; | > | > | | > | > | # Failed test 'use Math::GSL::Matrix;' | > | > | # at t/00-load.t line 14. | > | > | # Tried to use 'Math::GSL::Matrix'. | > | > | # Error: Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for module Math::GSL::Linalg: /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined symbol: gsl_linalg_QR_TR_decomp at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187. | > | > | # � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11. | > | > | # Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. | > | > | # BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. | > | > | # Compilation failed in require at t/00-load.t line 14. | > | > | # BEGIN failed--compilation aborted at t/00-load.t line 14. | > | > | ok 8 - use Math::GSL::Poly; | > | > | not ok 9 - use Math::GSL::MatrixComplex; | > | > | | > | > | It seems that the 2.7 upload broke the ABI of libgsl25 by removing | > | > | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from | > | > | entering testing because of this regression in libmath-gsl-perl_0.42-1. | > | > | | > | > | Looks like upstream Math-GSL-0.43 probably no longer references this | > | > | symbol, but it's not in Debian yet and I haven't built and verified that. | > | > | | > | > | Clearly at least something must be done on the libgsl side. Not sure if | > | > | it needs to restore the symbol or bump its SONAME, or if just a Breaks | > | > | on older libmath-gsl-perl versions is enough. (See policy 8.6.2) | > | > | > | > I am not fully sure what they are doing. They do increment values sometimes, | > | > sometimes they keep them. I mostly just followed along. | > | > | > | > We also for a time tried to accomodate lagging Debian packages. I do not | > | > think that that winnable strategy long term. | > | > | > | > I could add a versioned breaks for libmath-gsl-perl. Can you send me a | > | > preferred expression? | > | | > | No, that would just paper over the problem and wouldn't be a proper fix. | > | | > | There are two options to fix this issue: | > | | > | * Unbreak the ABI by reintroducing the removed symbols. | > | > I think we tried that a few gsl release ago and I don't think it was a success. | > | > | * Bump the SONAME and change the package name. This will trigger a | > | transition and the reverse dependencies will be rebuilt. | > | | > | In any case, the best idea is to talk to upstream. If removal of the | > | symbols was intentional, please ask them to bump the SONAME. | > | > It is AFAICR the opposite: upstream *did* the change years ago, we decided to | > paper over but at some point that becomes too much. Upstream is, in my book, | > the best judge of their code, and if they deprecated / changed something | > years ago then client packages need to (eventually) adapt. | | gsl 2.7 was released in June 2021. So the removal of this symbol is | recent. I see no patches that would have kept that symbol around for | longer than it was needed. In fact, diffing 2.6 and 2.7 suggests that | gsl_linalg_QR_TR_decomp was simply renamed to gsl_linalg_QR_UR_decmp. | | So I'm afraid I am unable to follow your reasoning. This is pretty clear | case of upstream forgetting to bump the SONAME.
Yes, possibly. I also grep'ed after sending the email. We did have such an attempt at a 'managed' transition before, and it didn't work so well. | > If the Perl package needs a (deprecated in the library) function and cannot | > change its code, maybe it can stub it locally? | | libmath-gsl-perl will eventually need to be fixed. Still, if gsl removes | a symbol from its public ABI, it needs to bump its SONAME. That's why we | have them and even encode it in package names. Yes. And I follow upstream. They didn't change :-/ Dirk | Cheers | | > | > Dirk | > | > | > | Cheers | > | | > | > | > | > | I've also filed the separate bug #993323 about libmath-gsl-perl failing to | > | > | build with GSL 2.7. That should be fixed just by upgrading it to 0.43. | > | > | > | > Right. | > | > | > | > Dirk | > | > | > | > | -- | > | > | Niko Tyni nt...@debian.org | > | > | > | > -- | > | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | | > | -- | > | Sebastian Ramacher | > | [DELETED ATTACHMENT signature.asc, application/pgp-signature] | > | > -- | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | | -- | Sebastian Ramacher | [DELETED ATTACHMENT signature.asc, application/pgp-signature] -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
