Bug#1001541: run-time shared lib not placed in package with proper name
On 12/11/21 22:22, Jochen Sprickerhof wrote:
> Package: ecl
> Version: 21.2.1+ds-1
> Severity: critical
> X-Debbugs-Cc: firstname.lastname@example.org
> according to policy:
> "The run-time shared library must be placed in a package whose name
> changes whenever the SONAME of the shared library changes."
> This breaks unrelated software, for example sagemath:
> $ sage -c "solve(x, x)"
> Traceback (most recent call last):
> File "/usr/share/sagemath/bin/sage-eval", line 10, in <module>
> File "<cmdline>", line 1, in <module>
> File "/usr/lib/python3/dist-packages/sage/symbolic/relation.py", line 1044, in solve
> return _solve_expression(f, x, explicit_solutions, multiplicities, to_poly_solve, solution_dict, algorithm, domain)
> File "/usr/lib/python3/dist-packages/sage/symbolic/relation.py", line 1283, in _solve_expression
> m = ex._maxima_()
> File "sage/symbolic/expression.pyx", line 1015, in sage.symbolic.expression.Expression._maxima_ (build/cythonized/sage/symbolic/expression.cpp:7931)
> File "sage/structure/sage_object.pyx", line 680, in sage.structure.sage_object.SageObject._interface_ (build/cythonized/sage/structure/sage_object.c:5480)
> File "sage/misc/lazy_import.pyx", line 329, in sage.misc.lazy_import.LazyImport.__getattr__ (build/cythonized/sage/misc/lazy_import.c:3870)
> File "sage/misc/lazy_import.pyx", line 191, in sage.misc.lazy_import.LazyImport.get_object (build/cythonized/sage/misc/lazy_import.c:2435)
> File "sage/misc/lazy_import.pyx", line 228, in sage.misc.lazy_import.LazyImport._get_object (build/cythonized/sage/misc/lazy_import.c:2842)
> File "sage/misc/lazy_import.pyx", line 224, in sage.misc.lazy_import.LazyImport._get_object (build/cythonized/sage/misc/lazy_import.c:2704)
> File "/usr/lib/python3/dist-packages/sage/interfaces/maxima_lib.py", line 92, in <module>
> from sage.libs.ecl import EclObject, ecl_eval
> ImportError: libecl.so.20.4: cannot open shared object file: No such file or directory
"The libecl.so file is changing too quickly and
is integrated with the ecl binary to such extend
that, after consultation with upstream, I will
not create a libecl package.
If ecl will reach a stable release (1.0 or so) and
some guarantees with respect to API stability
can be make I will reconsider this decision."
This is still true 13 years later. ecl is using its version (which is based on the year) as SONAME...
And sagemath is not unrelated software: maxima-sage and sagemath are the only packages in Debian with Depends: ecl. We are always making sure that maxima-sage and sagemath are rebuilt with every new ecl version, however sagemath 9.2 in Debian was already so broken that it didn't matter (look at the number of bugs fixed by sagemath 9.4-1).
Creating a library package for ecl would just mean that it would have to go through NEW for every new version with no real benefit.
Do you insist that I do that?