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

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")



Re: David Kalnischkies 2019-07-09 <[🔎] 20190709133107.gvib2ibj6w36j447@crossbow>
> A) For a user with "debian stable" in sources.list the change of the
> Codename from buster to bullseye is a giant leap which should not
> be done carelessly or even automatically in the background.

I agree that stopping "apt-get update" here makes sense.

> B) For a user with "debian buster" in sources.list the change of the
> Suite from e.g. stable to oldstable is an important event as well; not
> right at this moment as there is a grace period, but security support is
> about to end and plans should be set in motion on how to deal with that.

Refusing to continue with non-interactive (!) operation here is
totally wrong. The system is configured perfectly fine to use
"buster", and just because buster is moving from testing to stable, or
stable to oldstable doesn't justify breaking 100s of installations in
my data center.

The message that I should probably be looking into dist-upgrading my
data center will be sent to me in form of debian-announce, the general
news, or whatever other mechanism. I need to get that message once,
not once per system. What I don't need is 100s of systems breaking
"apt-get update" because that means I won't get monitoring messages
about security updates either (where one message per system makes
sense).

> APT isn't a newspaper, but at least for me it seems wrong that the one
> tool people associate with getting packages has absolutely nothing to
> say about big events at the vendor who issues my packages.

If you chose to send a message, that's ok, but the message must not
break non-interactive, unattended apt-get operation.

(At the very least, don't break "apt-get". For more fancy things,
there's "apt".)

> A Release file can declare that it will "soon" change its the value of
> a field to foo and apt clients can notify users about this so

Fwiw, I think this is seriously overengineered. We can't really test
it, and there's high chances the feature will break (itself or
something else) more than it might fix in practise.

Christoph


Reply to: