systemd-tmpfiles[16742]: [/usr/lib64/tmpfiles.d/sudo.conf:6] Line references path below legacy directory /var/run/, updating /var/run/sudo/ts → /run/sudo/ts; please update the tmpfiles.d/ drop-in file accordingly.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e4fbb2d676e441d5b121752b1e06558d4c970bd7 commit e4fbb2d676e441d5b121752b1e06558d4c970bd7 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-08-20 16:00:51 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-08-20 16:01:41 +0000 app-admin/sudo: always install tmpfiles - We now always install tmpfiles, even for non-systemd users. This should help some SELinux users. - rundir changed from /var/run to just /run [Bug 66104] Closes: https://bugs.gentoo.org/661004 Package-Manager: Portage-2.3.47, Repoman-2.3.10 app-admin/sudo/sudo-1.8.23-r2.ebuild | 240 +++++++++++++++++++++++++++++++++++ app-admin/sudo/sudo-1.8.24.ebuild | 45 ++++--- app-admin/sudo/sudo-9999.ebuild | 17 ++- 3 files changed, 277 insertions(+), 25 deletions(-)
Can this fix be changed ... there is no need for tmpfiles to be present. This does not appear to be a requirement for upstream either. A systemd or tmpfiles use flag would allow the desired outcome.
(In reply to Jonathan from comment #2) You can disable it at run time by creating a symlink to /dev/null. ln -s /dev/null /etc/tmpfiles.d/sudo.conf
Hi Mike - thanks for your response. Would this prevent a build time dependency on tmpfiles? I do not have tmpfiles installed or need it for anything at the moment. I'd prefer not to add it to package.provided which I could imagine may break things silently in future ... my only other option at the moment seems to be using an overlay and removing tmpfiles from inherit in the local ebuild.
(In reply to Jonathan from comment #2) > Can this fix be changed ... there is no need for tmpfiles to be present. > This does not appear to be a requirement for upstream either. > A systemd or tmpfiles use flag would allow the desired outcome. Any OpenRC version in repository will pull in virtual/tmpfiles which will pull in sys-apps/opentmpfiles on most systems. Systemd has tmpfiles built-in. What's your problem with tmpfiles service? It's not like that opentmpfiles is a big package and pulls in a lot of dependencies.
(In reply to Thomas Deutschmann from comment #5) > (In reply to Jonathan from comment #2) > > Can this fix be changed ... there is no need for tmpfiles to be present. > > This does not appear to be a requirement for upstream either. > > A systemd or tmpfiles use flag would allow the desired outcome. > > Any OpenRC version in repository will pull in virtual/tmpfiles which will > pull in sys-apps/opentmpfiles on most systems. Systemd has tmpfiles > built-in. What's your problem with tmpfiles service? It's not like that > opentmpfiles is a big package and pulls in a lot of dependencies. Description for opentmpfiles: A standalone utility to process systemd-style tmpfiles.d files I do not currently have opentmpfiles installed on any of my systems and have been managing OK up until this point. I have not yet encountered a compelling case for installing it.
This is Gentoo. Of course you can avoid *any* package. But if you want us to change something you need to provide a valid reason. Just saying "I don't use that package" (which is provided by default on any default Gentoo system) is not enough.
Gents - thanks for your replies. I think the approach taken introduced an unnecessary dependency. I seriously doubt that I will convince you to change things ... so I will not take up any more of your time. I'll go with a local overlay until I find a compelling reason to install opentmpfiles. Regards Jonathan