Bug#1012768: Bug#1012785: libgsasl7 depends on outdated gsasl-common version 1.10.0-5
On 2022-06-14 12:59:37, Simon Josefsson wrote:
> tis 2022-06-14 klockan 01:36 +0000 skrev Felicia P:
> > Package: libgsasl7
> > Version: 1.10.0-5+b1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > libgsasl7 depends on gsasl-common 1.10.0-5 however the current
> > version of gsasl-common is now 1.11.3-2
>
> Thanks -- this is related to the transition to libgsasl18, so cc'ing
> 1012768 too. Any help to resolve this would be appreciated! I must
> admit that my brain cannot really understand all the complexities
> around library transitions.
>
> The situation appears to be:
>
> 1) Testing contains libgsasl7 1.10.0-5 that has a hard versioned
> dependency on gsasl-common 1.10.0-5 for translation files.
>
> 2) Unstable now has libgsasl18 1.11.3-2 that depends on gsasl-common
> 1.11.3-2.
>
> 3) Libgsasl7 is no longer built by the gsasl source package, and the
> idea is that it should go away.
>
> 4) The old libgsasl7 is not installable since it depends on a gsasl-
> common package that is no longer in unstable.
>
> What should be done here?
>
> I guess the idea is that all packages that are built against libgsasl7
> is going to be NMU'd through the transition, so that they are built
> against libgsasl18 instead. Then this shouldn't be a problem.
While this won't be a problem in testing and unstable once the
transition is done, it could be a problem for bullseye -> bookworm
upgrades. In the worst case, this may make it harder for apt to find an
upgrade path and might have unintended side-effects on reverse
dependencies. For example, for upgrades to bullseye we faced issues with
a library that had postgresql extension modules as reverse dependencies
which also transitioned between postgresql versions where it would have
been desirable to keep the old binary packages installed for the
database migration.
Whether this is a problem for libgsasl, we'll see once upgrade tests for
bullseye -> bookworm are started.
> However, maybe something more should be done anyway. Some ideas:
>
> A) We declare that gsasl-common >= 1.11.3-2 conflicts with libgsasl7.
> Doesn't really solve anything, but maybe it will lead to libgsasl7
> being uninstalled automatically?
That won't help. libgsasl7's strict dependency on gsasl-common
will already force its removal when gsasl-common is upgraded.
> B) Somehow drop the gsasl-common dependency? It only contains
> translations, which works for both libgsasl7 and libgsasl18.
If gsasl-common only contains translations, would a Recommends:
gsasl-common (>= ${source:Version}) (or Depends) be enough? The solution
with Depends would not improve the situation for this transition, but
only for the next one.
> C) Change the versioning dependency, so that new gsasl-common satisfy
> the old libgsasl7 dependency -- but I'm not sure that's possible,
> libgsasl7 depends on the same version of gsasl-common.
That won't be possible … unless SRMs accept such a change in stable.
> I guess this means that libgsasl7 and libgsasl18 cannot be installed on
> the same system ever, due to the gsasl-common versioned dependencies.
> That is unfortunate, since there is no real problem with having both
> versions installed.
>
> Maybe B) is the right solution?! We could move the translations into
> libgsasl18 and drop gsasl-common. Then old libgsasl7 could depend on
> gsasl-common and things will work, and you could have libgsasl18
> installed too -- however, they would conflict in files since both ship
> the same translation files... unless we modify the filenames so they
> live in separate directories or basenames. I'm not sure that is worth
> it.
Note that this requires the translation files contained in libgsasl18
to be versioned exactly in the same way as the shared library. See Policy
8.2.
Cheers
> It may also be that we can't fix this problem, and just live with the
> consequences. What is the real problem here? All dependencies on
> libgsasl7 should be rebuilt and then link to libgsasl18. Libgsasl7
> will disappear from testing shortly.
>
> I wonder if it was a mistake to put translations in gsasl-common?! I
> recall a lot of thought went into that but it was many years ago and
> maybe the best practice around this has changed.
>
> /Simon
--
Sebastian Ramacher
Reply to: