Am 04.05.2018 um 13:47 schrieb Michael Biebl: > Dropping #TMPFILES# means, systemd-tmpfiles will act on all tmpfiles. > This would be a bit like if upgrading rsyslog would restart all system > services (including rsyslog). That doesn't feel right. > So I don't think dropping #TMPFILES# is the right approach.
To iterate on that: We ship quite a few tmpfile configs and during a (dist-)upgrade systemd-tmpfiles will be called multiple times. It seems wasteful, if systemd-tmpfile would act on all files over and over again. More importantly though, not all resources, as required in the tmpfile might be available when such a systemd-tmpfiles call is made. There is a time window between the package being unpacked and the tmpfile existing on disk and the package postinst being run, which e.g. needs to setup a user that is referenced in the tmpfile. Admittedly, this is less of an issue for tmpfiles then for service files. One valid use cases this touches though is, that overriding tmpfiles in /etc/tmpfiles.d should be supported. I.e. if there is a /usr/lib/tmpfiles.d/dbus.conf and an admin wants to tweak that by shipping a /etc/tmpfiles.d/dbus.conf, I don't think the package should override that. Afaics, this could easily be fixed by only using the name of the .conf file, not the full path, so dh_installsystemd/dh_installinit would have to generate systemd-tmpfiles --create dbus.conf instead of systemd-tmpfiles --create /usr/lib/tmpfiles.d/dbus.conf Felipe et al, what do you think? (CC pkg-systemd-maintainers to have more eyes on this) Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
