On Thu, 2021-08-26 at 13:50 +0200, Philip Hands wrote: > Luca Boccassi <bluca@debian.org> writes: > > > On Thu, 2021-08-26 at 12:16 +0200, Simon Richter wrote: > > > Hi, > > > > > > On 8/26/21 8:38 AM, Marco d'Itri wrote: > > > > > > > > By my definition, these have never been working correctly, but > > > > > semantics I guess. > > > > > > > It is not semantics. You keep saying that countless Debian and Ubuntu > > > > systems are not working correctly, but since this obviously does not > > > > reflect the experience of the owners of these systems then just about > > > > everybody will believe that you are wrong about merged-/usr. > > > > > > 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. > > > > > > Simon > > > > Precisely - and the correct technical question is, how many bug reports > > were opened by users? > > While I'm sympathetic with the argument that a lack of bug reports > suggests that the theoretical problems (that I hope we all agree, do > exist) seem not to be exhibiting themselves in the wild, it is very far > from proof. > > If some random file disappears on your system one day, what happens? > > Most likely, nothing, and you never notice. > > Possibly, your system starts to misbehave. What do you do then? > > If you're a naive user, such as a recent arrival from Windows, then > misbehaviour is something that you've been trained to expect and you > install from scratch. The idea of reporting a bug never enters your > head. > > If you're aware that this sort of thing really should not happen, then > what happens next is probably down to how busy you are. If you're > busy, you probably check your SMART stats, and having convinced > yourself that the disks are OK, either restore from backup and check > for what ealse is missing, or use debsums to see the extent of the > damage and reinstall a package or two. Again, since you're only > trying to get back to work, and didn't track down the cause, no bug > report. > > The only bug reports you're going to get about this are either going to > be the useless "Something didn't work" bugs, that I doubt would ever get > tied to this cause, or the ones submitted by experienced, diligent, and > time-rich bug reporters (which is a rather rare combination). > > The fact that we don't see bug reports should surprise no one. > > Cheers, Phil. Actually in unstable (not in a release) this bug was observed, caught, properly reported and fixed: https://bugs.debian.org/953562 which would suggest these instances can and have been indeed detected when they happened - but anyway, that's why the full quote without the cut is: > Precisely - and the correct technical question is, how many bug > reports > were opened by users? 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. Conversely this > doesn't mean the dpkg database bug shouldn't be fixed, 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. IE, it's fine to think about all the possible ways things can go wrong, but the solutions need to be proportionate. So proposing to trash everything and going against the TC decision in absence of any user report and any knowledge from anybody of an actual breakage in buster/bullseye/19.10/20.04/20.10/21.04 is as far from proportionate as one can possibly be, just as suggesting to revert multiarch because 'apt install bash:ppc64el' breaks an amd64 machine beyond repair would be completely unreasonable. Am I suggesting the replaces+move issue should be ignored? No, hence the second part of the quote that was cut: > 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? -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part