Your message dated Sat, 25 Jun 2022 14:07:32 +0200 with message-id <yrb6hk7jekkre...@ramacher.at> and subject line Re: Bug#1012768: Bug#1012785: libgsasl7 depends on outdated gsasl-common version 1.10.0-5 has caused the Debian Bug report #1012768, regarding transition: gsasl to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1012768: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012768 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: release.debian.org User: release.debian....@packages.debian.org Usertags: transition Severity: normal 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";
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---On 2022-06-17 13:39:07, Simon Josefsson wrote: > 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. >From the transition perspective, it's pretty clear: make sure that the 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, ... > > 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. ..., 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 > > /Simon > -- Sebastian Ramacher
--- End Message ---
