Hi.  I'm requesting transition of 'gsasl' from 'libgsasl7' to
'libgsasl18' due to an ABI bump (removal of obsolete APIs).

The package has been uploaded to experimental, and reverse dependencies
appears to build fine since fortunately nobody appeared to rely on the
obsolete APIs:

https://salsa.debian.org/xmpp-team/gsasl/-/pipelines/388503

I'm also upstream and plan to release 2.0.0 within days that will be
identical to 1.11.3 that is in experimental now, but an upload 1.11.3 to
unstable is a good idea meanwhile.

/Simon

Ben file:

title = "gsasl";
is_affected = .depends ~ "libgsasl7" | .depends ~ "libgsasl18";
is_good = .depends ~ "libgsasl18";
is_bad = .depends ~ "libgsasl7";

Control: tags -1 confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gsasl.html

Feel free to go ahead whenever you're ready.

Cheers

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 ?

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.

That won't help. libgsasl7's strict dependency on gsasl-common
will already force its removal when gsasl-common is upgraded.
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.

That won't be possible … unless SRMs accept such a change in stable.

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
-- 
Sebastian Ramacher

Okay, this statement, and your entire email, makes me believe that the
situation is fine for this transition, but we should continue discuss
if there is something to be improved to handle bullseye->bookworm
upgrades.  Right?   Maybe dist-upgrades is a consideration for
transitions too, but it helps (me) to separate the issues.

Right.  I can't help but feel unsatisfied by relying on testing rather
than a complete understanding of what is supposed to happen.

I would have thought piuparts testing (which I did) would catch
problems like this.  Maybe I misunderstood what I tested, or it has to
be tested in a different way.

I think the upgrade problem will go away once the transition is
finished.

Yes perhaps -- libgsasl7 and libgsasl18 works without gsasl-common but
translations will be broken.  Translations shouldn't be broken, hence a
'Required:' field.  I guess these things are subjective though.

Indeed, and it wouldn't help if someone didn't upgrade to a "fixed"
stable gsasl package either, but went directly from current 'gsasl' in
stable to unstable.

Reading

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#shared-library-support-files

makes me believe the situation is correct here: translations do not
change between library SO versions and should thus not be in the
libgsasl7 or libgsasl18 package, and putting them in a gsasl-common
seems to be the recommended approach.  However, translations is such a
widespread class of files that maybe they are discussed elsewhere in
the policy manual, but I can't find any reference now.

Maybe what is the problem is the hard versioned dependency from
libgsasl7 and libgsasl18 on gsasl-common?  Maybe it shouldn't be
versioned at all, or a >= condition?

/Simon

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

Sleeping on this, how about libgsasl18 declare a dependency on 'gsasl-
common (>= 1.10.0-3)' instead of 'gsasl-common (= ${source:Version})'?

Then old libgsasl17 with gsasl-common can coexist with new libgsasl18. 
 
We would want gsasl-common to be upgraded to >= 1.11.3-2 eventually,
but it can only happen once libgsasl7 is removed from the system,
allowing the latest version of gsasl-common to be installed rather than
the hard versioned dependency from libgsasl7.

I suppose we should let the transition finish first, and then address
this.

/Simon

Hi Simon

Right, in general the goal is that the shared library packages are
co-installable to ease the upgrades. That's one of the motivations
behind Policy 8.1.

The automated tests only cover what they can. They essentially just give
some assurance that apt is able to find an upgrade path where the
removal of libgasl7 is a valid solution and that this (dist-)upgrade can
be performed without errors. They do however not cover cases where, say,
an admin needs to upgrade database cluster from one database server
release to the next one and thus needs the packages from bullseye and
bookworm installed at the same time. Now, if libgasl7 would be involved
and force the removal of the bullseye packages, that would be rendered
impossible (or would require a lot more work for users).

(As said earlier, I don't know if libgasl7 has reverse dependencies
where this could be an easier. But I'd prefer if we wouldn't have to
find out during the freeze.)

We have both packages depending and recommending their translations.
This can be argued both ways …

… if possible, an unversioned dependency would help a lot.

Cheers

Considering that an uncoordinated ghc transition has been started,
please consider implementing this change now. britney is currently
unable to migrate gsasl as it would cause packages to be uninstallable
in testing:

trying: libvmime/amd64 gsasl libvmime/s390x mailutils/arm64 mailutils/mips64el mailutils/armhf libinfinity/armel libvmime/armhf mailutils/i386 libvmime/mips64el mailutils/amd64 libinfinity/armhf libinfinity/s390x libinfinity/ppc64el mailutils/mipsel libvmime/arm64 libvmime/armel mailutils/ppc64el mailutils/s390x libinfinity/arm64 libvmime/mipsel libinfinity/amd64 mailutils/armel libvmime/ppc64el libinfinity/mips64el libinfinity/mipsel libinfinity/i386 libvmime/i386
skipped: libvmime/amd64 gsasl libvmime/s390x mailutils/arm64 mailutils/mips64el mailutils/armhf libinfinity/armel libvmime/armhf mailutils/i386 libvmime/mips64el mailutils/amd64 libinfinity/armhf libinfinity/s390x libinfinity/ppc64el mailutils/mipsel libvmime/arm64 libvmime/armel mailutils/ppc64el mailutils/s390x libinfinity/arm64 libvmime/mipsel libinfinity/amd64 mailutils/armel libvmime/ppc64el libinfinity/mips64el libinfinity/mipsel libinfinity/i386 libvmime/i386 (39, 0, 73)
    got: 41+0: a-1:a-22:a-0:a-0:i-0:m-17:m-0:p-0:s-1
    * mips64el: dico, dico-module-guile, dico-module-python, dico-module-wordnet, dicod, jabberd2, libghc-gsasl-dev, libghc-gsasl-prof, libgsasl7, libjreen-qt5-1, libjreen-qt5-dev, mpop, msmtp, msmtp-mta, mutt, pokerth, pokerth-server

Cheers

fre 2022-06-17 klockan 09:50 +0200 skrev Sebastian Ramacher:
common was introduced recently with bullseye, and all versions of
gsasl-common will work with both libgsasl7 and libgsasl18 -- the only
problem on version mismatches is that translations may be missing (or
too old, but that's not serious...).

Is there any point in fixing libgsasl7's hard versioned dependency on
the old gsasl-common in bullseye?  I'm not sure how big of a problem
that will be.  Maybe the change above is sufficient to allow smooth
upgrades anyway: libgsasl7+gsasl-common 1.10 can coexist with
libgsasl18, and gsasl-common 1.11.x can be installed when libgsasl7 is
no longer needed and removed.

What IS the best practice wrt shared library versioning transition with
translations?  That is not clear to me.

The problem is that typically translations are not co-installable since
they use the same filename even between shared library versions.
Putting them in packages gsasl-common7 and gsasl-common18 could be one
approach, but the files they install would conflict anyway.  However it
seems like a workaround for a limitation in the package dependency
handling: translations are not versioned the same way as the shared
library API.

/Simon

shared library packages stay coinstallable for stable -> testing
upgrades. But there is no good general answer for data and translation
files. Depending on how important they are, I'd use Recommends or
unversioned Depends. And if they are super important, ...

..., one can always make sure that the filenames of the translations are
versioned in the same way as the shared library. (I've done that in the
past, but is's probably not worth the effort and I would use Recommends
now.)

Cheers

I reached the same conclusion, and I'm preparing a 2.0.0-2 that weakens
the Depends: gsasl-common to a Recommends.  Thanks for discussion and
help with the transition, all looks good now.

/Simon