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
