Re: inkscape not installable from jessie-backports (depends libgsl10ldbl)
On Thu, 30 Mar 2017 at 15:12:08 +0200, Thibaut Paumard wrote:
> As a first step, you can do without a transition: libgsl2 and
> libgsl0ldbl would simply need to both depend on libgslcblas0.
...
> I am not sure whether it would be OK to do it immediately in unstable
> because the wording of Policy 8.1 does not make it clear to me whether
> the current situation is RC buggy or only importantly buggy:
> "If you have several shared libraries built from the same source tree,
> you may lump them all together into a single shared library package
> provided that all of their SONAMEs will always change together. Be aware
> that this is not normally the case, and if the SONAMEs do not change
> together, upgrading such a merged shared library package will be
> unnecessarily difficult because of file conflicts with the old version
> of the package. When in doubt, always split shared library packages so
> that each binary package installs a single shared library."
If in doubt, ask the release team what they think. They will often
accept Severity:important bug fixes if the solution is not intrusive.
Is there a bug open already?
The release team are generally in favour of things that make their job
easier, and Policy §8.1 compliance makes their job easier. I am not a
release team member, but I've helped with enough ABI transitions to know
that libraries that violate Policy §8.1 are really annoying.
Whether this is fixed in stretch or not, please stage this change in
experimental, so that it can land in stretch (if accepted) or in buster
as soon as possible after stretch is released (otherwise).
I think mechanically deriving package names from ABI names
(libgslcblas.so.0 -> libgslcblas0, 'import foo.bar' -> python3-foo.bar,
SomeGLibThing-2.0.typelib -> gir1.2-someglibthing-2.0) is an important
factor in keeping Debian working correctly.
> On the longer run, you would indeed want to drop that dependency, which
> would then require a transition so that lbgslcblas0 gets added to the
> dependencies of each binary that actually links against the library.
> Such a transition would clearly not be OK for unstable now.
This seems like a job for the buster release cycle, with appropriate
Breaks added to lbgslcblas0.
S
Reply to: