#1017 Tmpfiles.d: The _tmpfilesdir directory shouldn't be unowned
Opened a year ago by rishi. Modified a year ago

@@ -4,7 +4,7 @@ 

  

  == tmpfiles.d configuration

  

- Asking the tmpfiles.d mechanism to create directories for you just involves dropping a file into `+%{_tmpfilesdir}+`. You will need a build dependency on systemd-rpm-macros in order to make use of this macro.

+ Asking the tmpfiles.d mechanism to create directories for you just involves dropping a file into `+%{_tmpfilesdir}+`. You will need a build dependency on systemd-rpm-macros in order to make use of this macro, and a runtime dependency on systemd to provide the `+%{_tmpfilesdir}+` directory itself.

  

  For example, if the package needs a few directories to be created in `+/run+` in order for it to run, the packager needs to create a file named `+%{name}.conf+` that is installed as `+%{_tmpfilesdir}/%{name}.conf+`. The file has one or more lines of the following format:

  
@@ -31,12 +31,15 @@ 

  

  == Example spec file

  

- In the spec file, the packager needs to install the tmpfiles.d conf file into the `+%{_tmpfilesdir}+` directory and also make sure the directory is included in the rpm.

+ In the spec file, the packager needs to install the tmpfiles.d conf file into the `+%{_tmpfilesdir}+` directory and also make sure that the rpm depends on the owner of the directory.

  

  ....

  # For the _tmpfilesdir macro.

  BuildRequires: systemd-rpm-macros

  

+ # To own _tmpfilesdir directory itself.

+ Requires: systemd

+ 

  # tmpfiles.d configuration for the /run directory

  Source1:  %{name}-tmpfiles.conf

  [...]

If a package is dropping a file into _tmpfilesdir, then installing the
package shouldn't lead to an unowned _tmpfilesdir directory. The
package should either depend on something that already owns that
directory (in this case systemd), or own the directory itself (in case
it wants to limit its dependency chain).

In fact, the text before the example spec file says:
"packager needs to ... make sure the directory is included in the
rpm."

That's the second option above.

On a stock Fedora 32 Silverblue system and a stock Fedora 31
Workstation, _tmpfilesdir is only owned by the systemd package.
Therefore, it might be better to have the documentation lean towards
the first alternative of depending on systemd. Ultimately, in reality,
systemd isn't such an onerous addition because all variants of Fedora
use it as part of the base OS, and by using the tmpfiles.d mechanism
the package is implicitly indicating a desire to use systemd.

rebased onto d19ea9e

a year ago

We could just add it to filesystem, no?

I agree about adding it to filesystem. For the container use case, it would be unfortunate for if systemd was pulled in as a dependency just because a package includes a potentially optional configuration file.

In fact, we should add other similar systemd directories to filesystem for the same reason. Checking a fedora:32 container image, I see the following candidates:

[carl@tassadar:~]$ podman run -it --rm fedora:32
[root@6b9524f53510 /]# rpm -qf /usr/lib/{sysctl.d,systemd{,/user,/system},tmpfiles.d,udev{,/rules.d}}
file /usr/lib/sysctl.d is not owned by any package
file /usr/lib/systemd is not owned by any package
file /usr/lib/systemd/user is not owned by any package
file /usr/lib/systemd/system is not owned by any package
file /usr/lib/tmpfiles.d is not owned by any package
file /usr/lib/udev is not owned by any package
file /usr/lib/udev/rules.d is not owned by any package

We could just add it to filesystem, no?

Or that, yes.

Metadata