Hi, On 8/26/21 1:17 PM, Luca Boccassi wrote:
Ideally the question whether a system works correctly would be a technical, not a political one that is based on a majority vote of people who do not look behind the facade.
Precisely - and the correct technical question is, how many bug reports were opened by users?
That is the majority vote by people who do not look behind the facade.
Strawmen can always be constructed, for example you can completely brick a system by running 'apt install bash:armhf' but that doesn't mean multiarch should be scrapped and reverted, it would be silly to suggest that - and yet here we are.
This is precisely the debate we would be having if there was a package that enables armhf as a foreign architecture whenever it is installed: it would not break systems on its own, but we'd have to be a lot more careful in other packages about expressing dependencies.
I have armhf enabled on my laptop, and the resolver has suggested replacing bash:amd64 with bash:armhf a few times -- but I know that my setup is unusual.
Conversely this doesn't mean the dpkg database bug shouldn't be fixed,
Keep in mind that this isn't a dpkg bug, because dpkg never created a filesystem layout that was inconsistent with its database; usrmerge did.
What we are talking about is adding a workaround for the usrmerge package to dpkg, and how to make sure that it works, regardless of whether the system has already been converted or not, if it has, which version of usrmerge was used, whether the package is currently installed or not, whether it will be installed as part of an upgrade and if so, which state the dpkg package is in at the time it is installed.
For example, a possible scenario could be that the system was converted with usrmerge version 9 (which modified dpkg.cfg), then the usrmerge package was deinstalled as a later version declared a conflict that the user resolved in favour of the other package, usrmerge hasn't been installed since, then during the upgrade to bookworm, a new version of dpkg is unpacked (but not configured yet), then a new version of usrmerge is unpacked, and then dpkg --configure -a is run.
So we need a list of things that need to happen to get back into a consistent state and a way of sequencing that inside the package dependency DAG.
so that the replace+move bug can't happen in the future, but it simply makes overblown and hyperbolic ideas such as "all systems are broken, revert everything" and "let's cancel the TC decision" appear counter- productive and deeply unhelpful toward finding an actual, realistic solution.
The TC decision does not specify technical details, which was a grave mistake because the implementation was so shoddy that I doubt the TC would have signed off on that, had they been consulted on the details.
Pretty much no one is interested in rolling this back, but a lot of people, me included, are indifferent and cannot see the benefits, especially as they consist mainly of things that used to work in the past, were broken during the systemd rollout and subsequently declared out of scope when people complained, so all users of these features have already left anyway.
An actual, realistic solution will work for all users, including those who have now installed or upgraded to buster from DVD, run offline and will upgrade to bookworm from DVD when it comes out.
Given this and the last few mails, it seems to me at this point the only possible way forward is what Timo and Ted suggested the other day, namely to have an external tool, possibly part of src:usrmerge, scan the dpkg database and fix it? Possibly on a trigger?
No. We couldn't sequence that correctly, we'd have to somehow make installation of the usrmerge package mandatory, and that tool would need to touch the dpkg database at a point where dpkg is active in the background.
It makes a lot more sense to have a dpkg-internal tool that can investigate the differences between the file system and the dpkg database, resolve conflicts (possibly in an interactive process when required by a corner case like the one I mentioned earlier -- luckily, these should be really rare) and then leave a consistent state again that allows package maintainers to use all dpkg features again after the bookworm release.
That will be a lot of work, and we cannot speed it up anyway because we're tied to the release cycle here, so I'd rather do this properly than deploy another paper mâché thing that then turns out to have another weird bug that will delay the transition to bookworm+2.
Simon
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature