Re: Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Mon, Apr 19, 2021 at 06:28:05PM +0200, Julian Andres Klode wrote:
> On Mon, Apr 19, 2021 at 06:08:23PM +0200, Julien Cristau wrote:
> > On Mon, Apr 19, 2021 at 06:01:18PM +0200, Julian Andres Klode wrote:
> > > I see. Nobody pinged me since then, but it is indeed fixed in the
> > > 1.8.5 stable update that at least one release team member was
> > > not exited about.
> > >
> > > https://salsa.debian.org/apt-team/apt/-/compare/1.8.2.2...1.8.5
> > >
> > > So it's up to the release team if they want 1.8.5 or whether we'll have
> > > to cherry-pick a subset of it into a 1.8.2.3. I think my opinion on that
> > > is clear - I don't want to maintain a 1.8.2.z branch, it's more work compared
> > > to just following the normal stable apt updates, and there's a lot less
> > > testing going on.
> > >
> > Please upload just that fix to buster; I don't care too much about the
> > version number you pick.
>
> Is there a buster point release before bullseye release, or should that
> be in buster-updates?
>
I don't know. It needs to make its way to spu soon either way.
> Given that buster is going to security support only soon anyway, I don't
> mind where I apply security updates to that much :D
>
>
> But I really do want to cherry-pick at least two other code fixes, and one test
> suite fix:
>
Can we defer these until after the AllowReleaseInfoChange change is
out, please?
Thanks,
Julien
> * https://salsa.debian.org/apt-team/apt/-/commit/cfee71c6f2d1478ce4d4ed74ef690ae1350ea403
> https://salsa.debian.org/apt-team/apt/-/commit/75f452c7309d66548c86a6526cbd65fc51a70039
>
> (really just one change, but it was split over two releases, first
> turned error to warning, next one ignores it completely; because it
> was in 2 releases in main so I kept it separate :D)
>
> too, they'll make immediate configuration errors non-fatal. Currently
> they are fatal in the sense that they are ignored and the upgrade runs
> and then it just exits with 1 at the end. So it does not change the
> outcome, it just makes the error reporting less silly.
>
> It is very likely that some upgrades on multi-arch systems fail erronously
> without them. To be fair, the multi-arch aspect is also fixed by
> https://salsa.debian.org/apt-team/apt/-/commit/7f65fa3843abc476cbba65c808abc5dd77835815
> but that changes ordering results, and is not strictly necessary.
>
> * And I want
> https://salsa.debian.org/apt-team/apt/-/commit/cfc6870e9b8ad119219ce5dc1871531006bb2d71
>
> to avoid people getting packages removed that stuff still depends on
> because their prerm script failed. This might happen during an upgrade
> to bullseye, and it's very very likely APT will not be able to recover from it
> - I've never successfully recovered a distribution upgrade that had a failure in the
> middle (and fwiw, all of them had, but they were my faults, really).
>
> * Also the testsuite-only change in
> https://salsa.debian.org/apt-team/apt/-/commit/730c5c861c32c9385dc862af8673984b12902343
> which makes things work reliably on debci armhf (no regression
> potential, wheee)
>
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer i speak de, en
>
Reply to: