Bug#1012768: Bug#1012785: libgsasl7 depends on outdated gsasl-common version 1.10.0-5
Hi Simon
On 2022-06-14 18:54:30 +0200, Simon Josefsson wrote:
> > > 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.
>
> 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?
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.
> > Whether this is a problem for libgsasl, we'll see once upgrade tests
> > for bullseye -> bookworm are started.
>
> 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.
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.)
> I think the upgrade problem will go away once the transition is
> finished.
>
> > > 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.
>
> 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.
We have both packages depending and recommending their translations.
This can be argued both ways …
> > > 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.
>
> 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.
>
> > > 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.
>
> 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?
… if possible, an unversioned dependency would help a lot.
Cheers
--
Sebastian Ramacher
Reply to: