Dear Maintainer,

libgsasl7 depends on gsasl-common 1.10.0-5 however the current version
of gsasl-common is now 1.11.3-2

tis 2022-06-14 klockan 01:36 +0000 skrev Felicia P:

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.

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?

B) Somehow drop the gsasl-common dependency?  It only contains
translations, which works for both libgsasl7 and libgsasl18.

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.

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.

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

But unstable also still has libgsasl7 1.10.0-5.

Isn't it possible to update libgsasl7 in unstable to 1.11.3-2 to match
gsasl-common's version or else just update the gsasl-common dependency
in libgsasl7 to 1.11.3-2 ?

Please close this bug.  It is no longer applicable.  Thanks!

tis 2022-06-14 klockan 22:57 -0700 skrev Felicia P:

Okay.  Bug #1012768 is still open and we can continue to discuss there
if there is anything that should be done -- right now, I prefer to wait
for the transition to finish and then worry about the upgrade
situation.

/Simon