Re: /usr-move: Do we support upgrades without apt?
Hi Matthew,
On Thu, Dec 21, 2023 at 02:42:56PM +0000, Matthew Vernon wrote:
> On 21/12/2023 09:41, Helmut Grohne wrote:
>
> > Is it ok to call upgrade scenarios failures that cannot be reproduced
> > using apt unsupported until we no longer deal with aliasing?
Let me thank David for clarifying what "using apt" means in exactly the
way I intended it.
As a result, I think the only "no" reply, I've seen thus far is from
Matthew here.
> I incline towards "no"; if an upgrade has failed part-way (as does happen),
> people may then reasonably use dpkg directly to try and un-wedge the upgrade
> (e.g. to try and configure some part-installed packages, or try installing
> some already-downloaded packages).
I incline to agreeing with the scenario you depict. This can reasonably
happen. I also think that David made a good case for it being unlikely
to manage oneself into the buggy situation that way. And then the
consequence is that you lost some possibly important files. If you ended
up fiddling with dpkg in a failed upgrade, would it be too much to ask
for running dpkg --verify? In the event you see missing files, you may
reinstall affected packages and thus have cured the symptoms for your
installation.
Say we extended release-notes saying that you should dpkg --verify after
the upgrade and more so if you happened to use dpkg directly in the
process and review the output. Would that address your concern?
> It may be that the mitigations necessary are worse than the risk, but I
> think the behaviour as described in #1058937 is definitely buggy.
I hope we all agree this is buggy. That's not the question. The question
at hand is whether this is a bug worth fixing or mitigating. We face a
lot of bugs in Debian and assign different severities. Here, the
preliminary analysis assigned a rc-severity which generally means it is
worth fixing. That's the thing I'm questioning here.
Also keep in mind that probably the majority of bullseye -> bookworm
upgrades have been performed already. In all those upgrades, nobody ran
into the issue and reported it. As David pointed out, it was encountered
by actively trying to make it break. It's the silent kind of failure, so
it may just have happened without people noticing.
Maybe we can all run dpkg --verify on our installations (in particular
those upgraded to bookworm or later) and report if they show anything
suspicious. Then we can better quantify how likely these issues happen
in practice.
I note that dpkg --verify does not currently work with --path-exclude.
I'm not sure whether that's a bug. Being a user of --path-exclude, I
note that I ran dpkg --verify on 5 very different systems and didn't
spot unusual things. This is anecdotal evidence and cannot prove the
absence of problems though. I'd be very keen to see at least one user
reporting such problems in a real upgrade rather than me trying to find
problems.
Helmut
Reply to: