tmpfiles config is only installed with systemd support enabled; should be independent

[a3s7p]

Describe the bug

The distro/systemd/tmpfiles-openvpn.conf tmpfiles config only gets installed if systemd support is enabled by ./configure --enable-systemd, despite there being distros which have a working tmpfiles provider but do not use systemd as the init system.

Enabling systemd support is not the correct solution, as this also installs the unit files and adds code through the ENABLE_SYSTEMD define, neither of which is desired on systems which do not use actually systemd as the init system.

Therefore, the coupling of tmpfiles support to systemd support is incorrect.

To Reproduce

On Gentoo with USE=-systemd, for example OpenRC:

# emerge openvpn

Expected behavior

There is a way to install the tmpfiles config for use by any tmpfiles provider without enabling systemd support.

Version information:

• OS: Gentoo Linux with OpenRC, maybe others
• OpenVPN version: any

Additional context

Installing the net-vpn/openvpn-2.6.8 package on Gentoo with OpenRC produces the following output:

* The tmpfiles processor exited with a non-zero exit code

On further investigation, this happens because the package for openvpn calls systemd-tmpfiles --create openvpn.conf as a post-installation step, but the openvpn.conf tmpfiles config is not installed on the system because systemd support is disabled by -systemd USE flag since OpenRC is used as the init system.

$ equery u openvpn
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
 * Found these USE flags for net-vpn/openvpn-2.6.8:
 U I
 - - systemd   : Enable use of systemd-specific libraries and features like socket activation or session tracking

In Gentoo, the systemd-tmpfiles binary is provided by the sys-apps/systemd-utils package.

$ equery b $(which systemd-tmpfiles)
 * Searching for /bin/systemd-tmpfiles ... 
sys-apps/systemd-utils-254.8 (/bin/systemd-tmpfiles)
$ eix sys-apps/systemd-utils
[I] sys-apps/systemd-utils
     Available versions:  254.5-r2^t 254.7^t (~)254.8^t {+acl boot kernel-install +kmod secureboot selinux split-usr sysusers test +tmpfiles +udev ukify ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" PYTHON_SINGLE_TARGET="python3_10 python3_11 python3_12"}
     Installed versions:  254.8^t(05:00:50 25.12.2023)(kmod split-usr tmpfiles udev -acl -boot -kernel-install -secureboot -selinux -sysusers -test -ukify ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" PYTHON_SINGLE_TARGET="python3_11 -python3_10 -python3_12")
     Homepage:            https://systemd.io/
     Description:         Utilities split out from systemd for OpenRC users

This package is depended upon by a few other crucial bits and it is therefore always installed on a Gentoo OpenRC system.

$ equery d systemd-utils
 * These packages depend on systemd-utils:
virtual/libudev-251-r2 (!systemd ? >=sys-apps/systemd-utils-251[udev,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
virtual/tmpfiles-0-r5 (!systemd ? sys-apps/systemd-utils[tmpfiles])
virtual/udev-217-r7 (!systemd ? sys-apps/systemd-utils[udev])

I suspect Alpine and other non-systemd distros also run into this.

I do not think this is a distro issue since the underlying assumption of the OpenVPN build scripts that a full systemd installation is the only possible tmpfiles provider does not hold true.

In this case we do not need the unit files or code for systemd since the init system is OpenRC but we do support and would like to have the tmpfiles config.

So ideally, these should be decoupled from each other, with --enable-systemd implying --enable-tmpfiles but --enable-tmpfiles being available independently of --enable-systemd and disabled by default.

I am happy to submit a patch if there is consensus that this is the correct approach.

[cron2]

Indeed, what our current tree does is not that useful.

I think the upstream source should never(!) install this file - if and where this gets installed is a distribution specific thing, so our installer should go, and it should be moved to the ebuild, depending on options set there (or always, if useful for Gentoo).

[a3s7p]

That also sounds reasonable.

I figured if there is an installer supplied by upstream then you would prefer that package maintainers use it. When the set of installed files is changed, the changes also get propagated to every distro mostly "for free". Ultimately I can't object to it being a distro-specific matter though.

If this is the definitive upstream position on the matter, then this issue can be closed and we will instead change the ebuild in Gentoo to install the file itself while referring to this issue.

[cron2]

"Upstream" tends to have different opinions on systemd, alas. So we need to discuss this and come to a joint decision (and then patch distro/systemd/Makefile* accordingly). So let's keep this issue open for now.