[Procedural note: I’m very busy with my day job this week, so I will be responding to messages related to this report in batch mode, once a day.]
On Mon, Sep 26, 2022, at 4:49 PM, Sam Hartman wrote: >>>>>> "Sean" == Sean Whitton <spwhit...@spwhitton.name> writes: > > Sean> - you might be lacking the full context of TC-involving > Sean> discussions over the past few months, but so far as I can see, > Sean> you are asking for us to undo a decision that we only just > Sean> made, which doesn't make sense. > > Sean, as someone who has tried to follow this for a while, I'm confused > by a third thing. > Doesn't the TC recommendation given additional weight by the RT that we > not migrate file paths until the dpkg bug has been fixed make it > impossible for the pre-conditions for disappearing files to happen? I may have misunderstood the TC recommendation here. I was under the impression that the “no migration of file paths” rule was *only* in effect until the release of bookworm, and that it was motivated by the need to continue supporting non-merged systems up till that point, not by the dpkg bugs. If the rule is in effect until the specific dpkg bug identified by Simon is fixed, then that does make the situation *somewhat* less dire, but I still stand on the request I made, because of: >>Several other equally dire scenarios >>are listed in https://wiki.debian.org/Teams/Dpkg/MergedUsr under the >>“merged-/usr-via-aliased-dirs” subheading, albeit only tersely.) > > I think that if you are going to ask for drastic action like you are > doing, a turse mention on a wiki page is not sufficient documentation. > Simon's mail got significant attention because he actually worked > through and documented the situation. > I and I believe several people who have looked at this situation believe > that the RT guidance will prevent the issue Simon raised from happening. I think this may get at the heart of the disconnect between my perspective and yours. You are apparently content to think that the issue Simon identified is the only issue that actually needs a remedy. I, on the other hand, am assuming that this is only one of potentially dozens of similar data-loss scenarios (not necessarily dozens of *bugs*; perhaps just several other scenarios that tickle the same bug) and that most of them are *not* addressed by the “no migration of file paths” rule. I believe this, fundamentally, because I believe Guillem Jover. You say that “if you are going to ask for drastic action like you are doing, a terse mention on a wiki page is not sufficient documentation”, and that would be fair if it was me who wrote the wiki page, but it was Guillem who wrote it, and *he’s the dpkg maintainer*. If he says there’s a situation where, quote, “dpkg and dpkg-divert are currently broken by this approach, will fail to notice file conflicts and will overwrite files” then I take that seriously, and what I want here is fundamentally for the project as a whole to take Guillem’s concerns seriously. This is why I said “to the satisfaction of the dpkg maintainers” in my original request. In particular, it should not be on me, or Guillem, to demonstrate how each of the problems listed on the wiki page can be triggered. It should be *the proponents of usrmerge* who are held responsible for fully investigating just how many data loss scenarios there are, and for proposing solutions. Given that they have spent the last five years, possibly more, *refusing* to do so, I think it is entirely reasonable for the project to demand a halt to their proposed change until they have done all of the due diligence that they *should* have done five years ago. I know that usrmerge has been planned for rather *longer* than five years now, but here’s the thing: No properly-written Unix program has any reason to *care* whether /bin is a symlink to /usr/bin. Therefore there is no justification for pursuing usrmerge with any kind of urgency. I can see the value from a theoretical system integration design perspective, and I don’t mind it happening *eventually*, but I do very much care that it not render my personal workstation (which has tracked unstable for 25 years now with no serious issues) unbootable. (Postscript: Let me be clear that I’m just a user of the distribution. I’ve never even considered becoming a DD. But as a longtime contributor to several key upstream projects for *all* Linux distributions, and as someone who *has* been running Debian unstable on his personal workstation for 25 years, I’d like to think that I know what I’m talking about when I say things like “no properly-written Unix program has any reason to care whether /bin is a symlink to /usr/bin”.) zw
