Order of the machine-id files

[Fridrich Strba]

Thanks Simon,

On 09/01/14 13:03, Simon McVittie wrote:
> This does sound to me like a system-integration issue: if you have both
> files, they should be identical. I would expect that anything that
> generates a machine ID (dbus-uuidgen and systemd-machine-id-setup)
> should try reading both locations: if its preferred location doesn't
> exist (or is syntactically invalid), but the other location does (and is
> valid), it should either do nothing, or copy the ID from the other
> location. Actually generating a new ID should be a last resort.

My analysis is that pulseaudio reads the id and keeps it. Most probably,
during the installation, it reads it before the dbus is even installed.
I by chance managed to reproduce this by deleting manually the
/var/lib/dbus/machine-id on one machine and forgetting about it. Then
during the dbus update we had, the file was regenerated and I realized
the problem when trying to do SIP from that laptop. Making both files
identical by making /var/lib/dbus/machine-id symlink to /etc/machine-id
(and a nice reboot) made the things to be good again. So, I am "fixing"
this in the post-install script of the package.

> If you want to make /etc/machine-id consistently "higher priority" than
> /var/lib/dbus/machine-id, please check the other D-Bus implementations
> (GDBus, libsystemd-dbus, dbus-java, ndesk-dbus) and check which priority
> order they use. If "consistently use /etc/machine-id" turns out to be
> simpler than "consistently use /var/lib/dbus/machine-id", I wouldn't
> oppose a patch for the D-Bus Specification to make it recommend this; at
> that point, it would become appropriate to change the implementation.

GDBus is reading them in the same order as dbus does. dbus-java master
does not even know about the /etc/machine-id (maybe I should patch
that). This brings the conclusion that I will just abandon my patch.

Thanks for the insight

Cheers

Fridrich