[Pkg-utopia-maintainers] Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback

[Simon McVittie]

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