[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1012768: marked as done (transition: gsasl)

Your message dated Sat, 25 Jun 2022 14:07:32 +0200
with message-id <Yrb6hK7jEKkReAvN@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 owner@bugs.debian.org
immediately.)


-- 
1012768: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012768
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
User: release.debian.org@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";

Attachment: 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 ---
Reply to: