Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
On Tue, 11 Jun 2024 at 18:05:21 +0200, Helmut Grohne wrote: > I looked for other cases where there would be a versioned dependency on > usr-is-merged and to my surprise dbus was literally the only one. I suspect many of the other packages that migrated from shipping systemd units in /lib/systemd to shipping them in /usr/lib/systemd had less dramatically bad failure modes if the system is still in the unmerged-/usr state - often the single service shipped in that package would not start, but the system as a whole would still boot, leading to a lower expectation that the maintainer must prioritize a response. smcv
Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
On Tue, Jun 11, 2024 at 03:31:04PM +0100, Simon McVittie wrote: > 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. How could I have missed this! Sorry. > Would the suggested versioned dependency on base-files offer the same? Yes. base-files (>= 13.3~) will directly ship the aliasing links in its data.tar and its preinst will fail if any of these links actually is a real directory (rather than being a symlink or absent both of which mean that after unpack there'll be a symlink). I looked for other cases where there would be a versioned dependency on usr-is-merged and to my surprise dbus was literally the only one. So given that we do not want to duplicate the conflicts into base-files and that dbus actually is the only package wanting to express this, I am now convinced that the originally proposed solution of adding the base-files alternative actually is a good solution for the problem at hand. Helmut
Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
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
Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
Hi Jonas, On Fri, Jun 07, 2024 at 05:00:44PM +0200, Jonas Smedegaard wrote: > dbus depends versioned on usr-is-merged, which is now a transitional > package depending on base-files. > > Please change the dependency to be declared like this: > > Depends: base-files (>= 13.3~) | usr-is-merged (>= 38~) > > That allows dropping the transitional package. I think this request is not reasonable as is. Let's find out what we really want here. The semantics of base-files (>= 13.3~) and usr-is-merged (>= 38~) actually differ and your proposed change weakens the promises. In particular, usr-is-merged declares Conflicts for a fair number of packages to ensure that certain bugs are not present. base-files does not carry these conflicts, so by adding the alternative you are implying that these conflicts would be no longer needed. Then when you do not need the Conflicts, you might as well change the dependency to unversioned usr-is-merged as the only important features (from a client package pov) that usr-is-merged gained with higher versions are those Conflicts. Once you weaken it to the unversioned usr-is-merged, the provides from base-files actually suffices. It does seem reasonable that someone added the version restriction by accident. For dbus, it was added via #1054650, but the bug log does not express why the version restriction was needed. It would also be conceivable to have base-files do versioned provides of usr-is-merged. I considered this and concluded that it was a bad idea, because base-files would have to also carry all those Conflicts then. We want base-files to be upgraded early and those Conflicts would cause it to get upgraded late even though they are only really needed in some cases such as dbus. Hence I intentionally opted for not copying the Conflicts and thus not doing versioned provides. Given the above, 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. In the event that the Conflicts are not important to dbus, the obvious solution is to drop the version. In this case, waiting for base-files to migrate is not required. In no case is adding a base-files alternative a good thing to do. Helmut
Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
On Fri, 07 Jun 2024 at 17:00:44 +0200, Jonas Smedegaard wrote: > Please change the dependency to be declared like this: > > Depends: base-files (>= 13.3~) | usr-is-merged (>= 38~) > > That allows dropping the transitional package. I don't intend to act on this until the updated base-files is in testing, which is waiting on both the usual migration delays and a manual unblock; but after that, sure, it can be part of the next update to dbus. smcv
Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
Package: dbus Version: 1.14.10-4+b1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 dbus depends versioned on usr-is-merged, which is now a transitional package depending on base-files. Please change the dependency to be declared like this: Depends: base-files (>= 13.3~) | usr-is-merged (>= 38~) That allows dropping the transitional package. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZjIJkACgkQLHwxRsGg ASGVAA/8CkEIMzV+iRqF2um5sPLta1EpDVN/9e3if7kGn2DQ9FZei7bK+zpK0LL6 3CWhH4ujCR2A0ci/5MZuNcNxbTuTrxgx5tCFKdqMXCdNj8UXWb5kAo6PRpUJ/yDs OhLX9TciAJUsQSVap8EXr7EmI+QsseKjYEt3fubr7TLWIsrih52UP/DSPEwLXs9b IFCu2P6P5EZAKMvgStPRT/UnayYDRNXuVy4sFbL3UL8bi6aVkKvUrd3zhTMsdpVQ DoLsweQqWW1ZZHuTBgC//8Hv9/qNckNF3WLvJPH9FUJwRpEd6UXDEDfOICxQD2qK pcWygS8ESaQ7RRvxmDXfH/S9kyivX2FVvyiHTOuQXauwLNLWQqqcmFAe5Orfcf+i nrqjiQz4RtYZgEYwV9/N6Wa+K9Vq4Fq93ul9RCZVLt3DmEY+tgCChHtAg9kc7n5/ 54CdN46PA0mco8ASQy+hY0sShdTNOKtrituSaX8xuhsifDU/JqZ3+GSJu0Ex+3SV 2msYTUN2GwBRyut014/HpmBwDfy9YSSS7EupvX1OZv6fFq+cddr6PU2FnzEa0rxg ewcV/1f9+gaN7mOtY+ojeRQ4kiToZZsKaVRmyOPZbmgKiwDVWIDCC1vm/60dHcGv PV+i75EEMbmbDqNex1quDwTRystO2ptLOyt0d8XPFvkC8duHpoE= =ZvrR -END PGP SIGNATURE-
