On Tue, 11 Jun 2024 at 13:16:21 +0200, Helmut Grohne wrote: > the only important features > (from a client package pov) that usr-is-merged gained with higher > versions are those Conflicts.
I don't think that is true. The (single!) change in usrmerge v38 was that it no longer implements the undocumented opt-out mechanism involving /etc/unsupported-skip-usrmerge-conversion, therefore any system with usrmerge (>= 38~) or usr-is-merged (>= 38~) is always going to be /usr-merged. This means that any package with a dependency on usr-is-merged (>= 38~) can safely assume that it will never be installable on systems where /etc/unsupported-skip-usrmerge-conversion has been used to delay the conversion to merged-/usr, even during a partial upgrade, and therefore it does not need to be defensively programmed so that it will either work as intended or fail cleanly with an obvious error message on unmerged-/usr. Specifically, either the system is already /usr-merged, or usr-is-merged.preinst will have already failed (somewhat cleanly) and the dependency will not be met. Either way, the new dbus will not get configured and therefore any failure is somewhat clearly not a dbus bug. Would the suggested versioned dependency on base-files offer the same? I could have implemented this without an external dependency by open-coding a check for merged /usr and graceful failure into dbus.preinst or dbus.postinst, similar to the one in usr-is-merged.preinst; but this didn't really seem like it should be my job, and I try to minimize the amount of load-bearing shell script that I'm responsible for. > For dbus, it was added via #1054650, but the bug log does not express > why the version restriction was needed. I had hoped that the extensive changelog entry justifying this change would be sufficiently clear, but in case it wasn't: The reporter of #1054650 was running in the unsupported configuration of a post-bookworm system with unmerged /usr, presumably having used /etc/unsupported-skip-usrmerge-conversion to suppress conversion from unmerged to merged /usr. Before dbus 1.14.10-2, even though this scenario was explicitly unsupported, in practice it worked anyway. After dbus 1.14.10-2, the unsupported scenario caused boot to fail, which was reported as a Severity: critical bug in dbus ("breaks the entire system"). I considered #1054650 to be a non-bug, because it is an unsupported scenario, and creating that scenario must have required acknowledging this by creating a file with "unsupported" in its name; but I was not willing to make myself responsible for closing a series of duplicate high-severity bug reports, with an increased likelihood of being flamed by angry unmerged-/usr users with each duplicate, and that's what I expected would happen if I didn't add some sort of mitigation promptly (especially if 1.14.10-2 had reached testing). As a result of our dependency system being as elaborate as it is, there tends to be a perception that if it has been possible to install a package successfully, then any failure to work as intended after that is automatically a high-severity bug that demands a priority response from the maintainer, even if it involves scenarios that have been widely publicized as unsupported. The addition of Depends: usr-is-merged (>= 38~) in dbus was intended to ensure that the unsupported scenario could not happen, instead of creating the perception that dbus was irretrievably broken and it was my fault. Being told that I am personally responsible for critically harming Debian is not an aspect of the maintainer role that I enjoy, even if it isn't actually true, and I try to minimize it if I can. I'm sorry if my attempts to protect myself have caused additional work for others. > it feels right to me that dbus pulls the physical > usr-is-merged package whose purpose at this time is forcing other > packages off the system >From my point of view, forcing other packages broken by merged-/usr off the system is only a side-effect, and the purpose of this dependency was to redirect the blame for "package does not work on an unsupported non-/usr-merged system" to whoever set up the unsupported situation and is now continuing to rely on it. smcv