> > 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? Maybe dist-upgrades is a consideration for
transitions too, but it helps (me) to separate the issues.
> 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.
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.
> > 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?
/Simon
Attachment:
signature.asc
Description: This is a digitally signed message part