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

Re: Planning for libidn shared library version transition



Simon McVittie <smcv@debian.org> writes:

> On Wed, 26 May 2021 at 19:18:24 +0200, Simon Josefsson wrote:
>> Andreas Metzler <ametzler@bebt.de> writes:
>> > Why not use a versioned Provides *instead* of the dummy package?
>> 
>> Yeah, I never understand exactly when these dummy packages are needed.
>
> My understanding is that they are usually still necessary for smooth
> upgrades from one stable release to the next, because apt's dependency
> resolver tries not to remove packages (to minimize risk of removing
> something you were relying on), and removing a "real" libidn11-dev
> package because its lockstep version dependency is no longer satisfiable
> will still count as removing a package, even if a new libidn-dev now
> Provides it.
>
> It's a probabilistic thing, because apt calculates a "score" for various
> options for the whole upgrade transaction and chooses the one with the
> highest score - on some systems it will be able to figure out the right
> upgrade transaction even without a transitional package, but on others it
> will not. Having a transitional package makes it more likely that the
> intended upgrade happens, because apt gives a high "score" to upgrading a
> package that was already installed.
>
> piuparts only routinely tests relatively small installations - there are
> periodic QA tests done on larger systems like the union of all desktop
> tasks, but those are more expensive to run.

Thanks -- you convinced me to prefer libidn is not a guinea pig for
testing something like this.  I do think it would be a wortwhile release
goal, at some point, to fix tooling so that dummy packages are no longer
necessary for package transitions.  The information to make proper
decisions for 'apt' should be there without using dummy packages, as far
as I understand.  On the other hand, there are probably more important
areas (say, 100% reproducible builds) to work on instead.

/Simon

Attachment: signature.asc
Description: PGP signature


Reply to: