I've updated a package for ddclient, based upon the Fedora spec file. It has the following file: $ cat /etc/tmpfiles.d/ddclient.conf d /var/run/ddclient 0755 ddclient ddclient - Meaning: Create /var/run/ddclient using user+group ddclient. This to store the PID file while running under a different user. The directory is only created when systemd boots. IMO, either systemd-tmpfiles should have an inotify or something, or there should be an rpm filetrigger to rerun systemd-tmpfiles. Note: /etc/tmpfiles.d is probably incorrect, it matches Fedora, but think this should be /usr/lib/tmpfiles.d.
Well, systemd-tmpfiles is totally independant from systemd daemon and it, by itself, has no daemon component so cannot really watch for changes via e.g. inotify etc. With packages I've just been putting: %post systemd-tmpfiles --create %{name}.conf In the packages that need them. We could do this with a file trigger to ease the packaging overhead I guess. That said as this is a "common" thing for RPMs I'd maybe rather look at the systemd.macros shipped with systemd and see if we cannot incorporate something into that such that we get a bit more of a standard approach to packaging that is used on other distros too? And yes, do not use /etc/tmpfiles.d for files provided by a package. This is an administrator area. We should only package in /usr/lib/tmpfiles.d/ (maybe I should add some lint errors? - need to do some for /var/run/ and /var/lock/ files too).
I prefer triggers for something like this over post commands. If you put something in a well known location, then a trigger is IMO the cleanest solution. Loads of lint errors would be nice. Basically for everything that should not be in /etc. I have files there from apache, initscripts, bind and ddclient. A %{_tmpfilesdir} macro would be nice for this, though be careful with the name of that macro, might get confused with /tmp.
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Version: 2 => Cauldron
Closing as OLD.
Status: NEW => RESOLVEDResolution: (none) => OLD