Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution
On 02/08/14 19:16, Luca Capello wrote:
> On Sat, 02 Aug 2014 14:35:33 +0100, Simon McVittie wrote:
>> D-Bus (/var/lib/dbus/machine-id) also regenerates its machine ID during
>> boot if required, although systemd (/etc/machine-id)
>
> BTW, /me wonders why two different files...
The idea came from D-Bus, whose developers wanted a way to say,
unambiguously, "this is the same machine", "this is a different
machine". The systemd developers considered that to be a sufficiently
useful concept that they wanted systems without D-Bus to be able to rely
on it.
systemd doesn't want to depend on the D-Bus location because it's
D-Bus-specific, isn't guaranteed to be available when pid 1 starts (it's
in /var), and there's no formal specification for where it is[1].
If everything goes well, whenever those two files both exist, they
should contain the same thing.[2]
> Is there a list of [files that need resetting] somewhere?
No, and in a set of packages as large as Debian, a centralized list (for
things beyond some vaguely-defined base OS that could reasonably include
systemd and dbus but probably not postfix) seems doomed to failure.
That's why I suggested a dpkg trigger that could distribute that
knowledge between the packages involved.
Having said that, the live-* suite of packages makes a good attempt at a
centralized list.
S
[1] The de facto standard is "what dbus does when configured with
--localstatedir=/var" because virtually all distros are FHS, but the
default in an unconfigured build from source is technically
/usr/local/var/..., because Autotools does not default to a FHS location.
[2] Existing installations that installed systemd first, and dbus (<<
1.8.2) later, might have them differ. Fortunately, this seems unlikely
to happen in Debian, since the sort of people who installed systemd on
wheezy systems probably already had dbus.
Reply to: