Control: reassign -1 src:dbus 1.12.20-3
On Mon, 10 Jul 2023 at 18:43:06 +0100, Luca Boccassi wrote:
> As a wild guess, maybe the split of src:dbus into multiple packages
> affected the order in which the postinsts run, and now systemd's runs
> first and creates /etc/machine-id, and then dbus-daemon's runs and
> creates /var/lib/dbus/machine-id.
The ordering here is not *meant* to matter, because dbus-uuidgen is meant
to copy /etc/machine-id if it already exists and has suitable contents,
and systemd-machine-id-setup is meant to copy /var/lib/dbus/machine-id
if *that* already exists and has suitable contents.
> mkdir -p "${DPKG_ROOT:-/}var/lib/dbus"
> dbus-uuidgen --ensure="${DPKG_ROOT:-/}var/lib/dbus/machine-id"
I think the regression here is that in attempting to respect DPKG_ROOT,
I replaced dbus-uuidgen --ensure (which copies an existing systemd
machine ID if one exists) with dbus-uuidgen --ensure=PATH (which doesn't).
This was at the same time as the split into dbus.deb / dbus-daemon.deb,
but it was an orthogonal change. bullseye is unaffected, bookworm is the
first release with this.
I'm sorry that it took so long to notice this. I should have had test
coverage that would have detected this error.
> There is a tmpfiles.d shipped by dbus-daemon that creates
> /var/lib/dbus/machine-id as a symlink to /etc/machine-id if it exists,
> but this snippet runs _after_ the dbus-uuidgen so effectively it is
> always a no-op on package install:
As an upstream, this is clearly the right thing to do, but as a
downstream, I'm intentionally not relying on it as load-bearing by
default. There is nothing in Debian that guarantees that /etc/machine-id
will be created, unless we happen to be booting with systemd, which
isn't guaranteed; and if it did get created, as far as I can see, there
is technically also nothing that guarantees that it won't subsequently
be deleted.
https://bugs.debian.org/745876 proposed creating the machine ID in
base-files as a basic Debian feature that any package can rely on,
but it was closed as wontfix.
See also https://bugs.debian.org/783716 for more background.
Of course, d-i doesn't provide a way to not install systemd-sysv, but
a vocal minority of users and developers use non-default installation
mechanisms to get a different init system and consider that to be
a critically important use-case; and I'm concerned that even if these
users got a machine ID generated during installation, they would delete
it as a perceived systemd'ism, and then complain loudly in the form of
RC bugs when D-Bus doesn't work because /var/lib/dbus/machine-id is now
a dangling symlink.
smcv
