On Sun, Oct 02, 2022 at 12:26:29PM -0700, Steve Langasek wrote:
> On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> > >What's the plan for upgraded systems with an existing /etc/apt/sources.list.
> > >Will the new n-f-f section added on upgrades automatically(if non-free was
> > >enabled before)?
>
> > So this is the one bit that I don't think we currently have a good
> > answer for. We've never had a specific script to run on upgrades (like
> > Ubuntu do), so this kind of potentially breaking change doesn't really
> > have an obvious place to be fixed.
>
> > Obviously we'll need to mention this in the release notes for
> > bookworm. Should we maybe talk about adding an upgrade helper tool?
We have already talked about apt release-upgrade for a couple of times,
but no time to implement it yet and the design needs to be talked
through how the target release can hook into apt to provide quirks.
We want apt release-upgrade too
1. rewrite sources for you if you want to
2. upgrade the system in three steps equivalent to
apt safe-upgrade --without-new-pkgs
apt safe-upgrade --with-new-pkg
apt full-upgrade
3. Hooks to customize the dependency solving (adding/removing packages),
and potentially arbitrary quirks.
Where things get awkard is that (1) we'd like declarative hooks where
possible, a deb822 file of hooks, but (2) we also need to perhaps add
new logic.
So there was an idea to build a binary package that ships a module that
can be loaded at runtime by apt. So apt would install that package first
before it can upgrade. Or you can make it be a shell script and have
hooks of Type: Shell. Or just add Depends to release file that requires
users to install a newer version of apt before they can use the
repository and then ship that in (old)stable-updates with the additional
types of hooks.
>
> I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
> uncounted upgrade issues over the years and I think something like this
> would be a nice addition to Debian as well. Two caveats:
>
> - Despite this being the sanctioned upgrade path in Ubuntu for over a
> decade, every single cycle we get bug reports from users who have run
> into issues because they have bypassed it and done the manual sed
> /etc/apt/sources.list && apt dist-upgrade. So in Debian where this has
> been the norm for /two/ decades, I would not expect this to substantially
> reduce the error rate in the first release where such a mechanism is
> introduced. (After all, whether telling users to use a new upgrader tool
> or telling them to manually add a component to sources.list, they will
> have to read the release notes to know about it!)
>
> - There are always some users that end up with buggy systems after upgrade
> despite using the supported interface because they upgrade to the devel
> release, and the release-upgrader is still under development up until
> release so they miss out on quirks being applied - and there is no
> interface for users to replay the quirks that they missed out on. Don't
> repeat the same design mistake.
That makes sense. So the idea for apt release-upgrade is to have a list
of quirks and each quirk can then have a test to see if it ran already.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Attachment:
signature.asc
Description: PGP signature