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? > > 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). You can configure half-installed packages, no problem, this is about unpacking (which is the first step in an install, where only Conflicts and Pre-Depends matter, if you are not deep into dpkg vocabulary) The "try installing" part is less straight forward. In general, you are running into dpkg "features" (e.g. not handling pre-depends) or into dpkg bugs (e.g. #832972, #844300): In the best case your system state became a bit worse and hence harder to "un-wedge". In the worst case a maintainer script has run amok as nobody tested this. But yeah, most of the time you will indeed be lucky and hence come to the unreasonable conclusion that its reasonable to call dpkg directly. Anyway, if your upgrade failed part-way, you are probably in luck given that its more likely the upgrade failed in unpack/configure than in removal – so if you aren't too eager to install more packages by hand but limit yourself to e.g. (re)installing the ones who failed you are fine as apt will have removed the conflictors already for you (or upgraded them, if that can resolve the conflict). But lets assume you are not: As you are driving dpkg by hand you also have the time to read what it prints, which in the problematic case is (as exampled by #1058937): | dpkg: considering removing libnfsidmap-regex:amd64 in favour of libnfsidmap1:amd64 ... | dpkg: yes, will remove libnfsidmap-regex:amd64 in favour of libnfsidmap1:amd64 (and the same for libnfsidmap2:amd64 as well. If your terminal supports it parts of these messages will be in bold) Note that the similar "dpkg: considering deconfiguration of …" which is the result of Breaks relations is not a problematic case. (Also note that this exact situation is indeed another reason why interacting with dpkg by hand is somewhat dangerous as you might not expect packages to be removed from your system while you just told dpkg to unpack something… just remember that the next time you happen to "dpkg -i" some random deb file onto your system.) That is of course no hint that a file might have been lost due to aliasing if you don't know that this could be the case, but on the upside it is not entirely a silent file lose situation either. We could write something in the release notes if someone happens to read them AND also encounters this message. Query your memory: Did you encounter this message before? Nothing in the /usr merge plan makes that particularly more likely to be encountered for a user and not all of the encounters will actually exhibit the file lose. So if you haven't – and I would argue that most people haven't – there is a pretty good chance you wont have a problem in the future either… So, in summary: Yes, there are theoretic relatively easy ways to trigger it with dpkg directly. That isn't the question. The question is if a real person who isn't actively trying to trigger it is likely to run into it by accident (and/or if such a person can even reasonably exist) so that we have to help them by generating work for many people and potentially new upgrade problems for everyone – or if we declare them, existing or not, a non-issue at least for the upgrade to trixie. And on a sidenote: I would advise to reconsider interacting with dpkg too casually – but luck is probably on your side in any case. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature