On Tue, 11 Jul 2023 at 14:14, Simon McVittie <s...@debian.org> wrote:
>
> 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.
Ah that explains it, thanks
> > 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.
Well, I don't think we should make the 99.5% of cases more fragile to
cater to an entirely hypothetical 0.5% that would actively damage
their own installation by deleting OS files for no good reason. If
someone wants to mess manually with /etc/machine-id and
/var/lib/dbus/machine-id it's fair that they are allowed to do that,
but it's also fair to tell them that they get to keep the pieces.
Kind regards,
Luca Boccassi
