On Mon, 28 Apr 2014, Michael Biebl wrote: > Am 28.04.2014 17:51, schrieb Santiago Vila: > > For now, /etc/machine-id is a configuration (or state) file for the > > systemd package. Documentation about machine-id even says that > > removing the file on reboots is mostly harmless (you could have a > > different machine-id every time the machine boots and nothing bad > > would happen). > > Hm, I don't see this recommendation anywhere. The machine-id man page > [0] at least doesn't give any advice like this.
(Hmm. Maybe you misread "Documentation" as "Recommendation"?) It's certainly not a recommendation, nor an advice. It's just something which is possible to do for stateless systems: "Optionally, for stateless systems, it is generated during runtime at boot if it is found to be empty." (See the same manpage URL that you quoted at the end) > If you are going to change machine-id, this will treat old journal files > as coming from a different system. I wouldn't consider that a harmless > consequence. Presumably, if you purge (not just remove) systemd to install another init system, you are not interested in those journal files. > [...] > > On the other hand, if you can show me another init system (which is > > not systemd) also using /etc/machine-id, we can reconsider about this. > > The reason why we want to see /etc/machine-id in base-files is actually > because it is not only used by systemd, but e.g. also by dbus. That's fine, but the issue here (I mean: the reason why I think this has no place in base-files) is not "used by systemd vs used by some other package as well" but "used by at least one essential package vs not used by any package which is essential". > Say you've installed both dbus and systemd, dbus will read and use > /etc/machine-id. If you now purge the systemd package (and > /etc/machine-id along with it), this will confuse dbus. Well: How would you fix that if base-files didn't exist? If the only solution is not to remove machine-id, then piuparts is wrong and keeping machine-id in the system should be allowed. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
