fre 2022-06-17 klockan 09:50 +0200 skrev Sebastian Ramacher:
> On 2022-06-15 11:38:11, Simon Josefsson wrote:
> > > 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.
> >
> > 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.
>
> 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:
I've uploaded it now. I dropped the versioning alltogether: gsasl-
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
Attachment:
signature.asc
Description: This is a digitally signed message part