Ed: updated title - it became apparent that opentmpfiles is what I wanted to avoid and I have tmpfiles with openrc-0.13.11 already
Ed2: the thread title should probably have been how to deal with tmpfiles while retaining openrc-0.13.11

I have been running Gentoo for some time and have managed to avoid things like systemd by having in /etc/portage/package.mask

I want to avoid things being silently broken so have up until now avoided adding anything associated with tmpfiles in package.provided.
I have noticed in this thread a package.provided entry has been suggested.
Is the approach I am currently taking really any better at revealing issues and avoiding package breakage than adding an entry in package.provided ?
Is there a better way of avoiding silent breakage ?

I did suggest a USE flag in sudo but since any openrc currently in the tree would install tmpfiles this is unlikely to be supported ...

Last edited by jonathan183 on Fri Sep 28, 2018 1:52 pm; edited 3 times in total

add to /etc/portage/profile/package.provided and use the regular sudo ebuild, no need for it in the local overlay (one less file to take care of)

opentmpfiles is being pulled in by tmpfiles.eclass by way of the virtual/tmpfiles, the above will fix that since the old openrc works just fine as is.
The above will work with anything that uses the tmpfiles.eclass.

The only file I see installed by -r2 that is different from -r1 (no tmpfiles) is /usr/lib/tmpfiles.d/sudo.conf

Code:

MSI sudo # cat /usr/lib/tmpfiles.d/sudo.conf
# Create an empty sudo time stamp directory on OSes using systemd.
# Sudo will create the directory itself but this can cause problems
# on systems that have SELinux enabled since the directories will be
# created with the user's security context.
d /run/sudo 0711 root root
D /run/sudo/ts 0700 root root

Draw your own conclusions. Note that I have not done an exhaustive analysis of the package to see if tmpfiles are referenced anywhere else.

Removing the inherit of the tmpfiles eclass, if that is all you do, is probably the wrong solution. It may work sometimes, but it will not define the functions normally provided by tmpfiles.eclass, so you will get errors in the ebuild (possibly non-fatal) about the absence of those functions. Faking the presence of virtual/tmpfiles is less trouble and safer. If allows the ebuild to install the tmpfiles configuration files (but you could delete them via INSTALL_MASK if you wish), so if you do later need to use the tmpfiles capability, the configuration files will already be there. They are only data files, so if you do not run a tmpfiles manager, they are inactive.

Personally, I'd find a way to provide working tmpfiles service on the system and then let the packages use tmpfiles as normal. If your chosen version of openrc does not natively handle tmpfiles, you will need some other processor for them. Standard processors may not accept your old openrc, so you might need a local patch to get the processor to work.

Regardless of the path you choose, keep in mind that your ultimate goal should be for the computer to do what you need. If you spend substantial time fighting the package system, you aren't spending that time doing something you like. Pick a solution that minimizes your ongoing system maintenance burden.

Personally, I'd find a way to provide working tmpfiles service on the system and then let the packages use tmpfiles as normal.

++
Unavoidable for:

jonathan183 wrote:

I want to avoid things being silently broken

tmpfiles is by packages not only used for a correctly set up /run or /tmp, but tmpfiles.eclass is also used for a correct setup of files in some /var/* directories which on some systems might be temporary.

The reason why sys-apps/opentmpfiles blocks <sys-apps/openrc-0.23 is that openrc provided the tmpfiles service on its own in versions 0.xx-0.22*.
So "actually" the blocker should be on a certain range of openrc versions, but ranges are not supported by portage/pms. (For users without an ancient openrc in their local overlay, the given blocker is a correct workaround in the absence of ranges.)
Therefore, the non-breaking solution is to put (and update from time to time) sys-apps/opentmpfiles into your local overlay, removing the blocker.

tmpfiles is by packages not only used for a correctly set up /run or /tmp, but tmpfiles.eclass is also used for a correct setup of files in some /var/* directories which on some systems might be temporary.

mv ... that is a misuse of the word(s) "correct[ly]", but we've been over this previously, so, again, when, and by what mysterious process, did these unnamed files in /var/* become "temporary"? ... that's a rhetorical question btw.

@jonathan183 ... that version of openrc includes opentmpfiles, and if you have 'tmpfiles.dev' and 'tmpfiles.setup' in the runlevel, then nothing unexpected should happen were you to package.provided sys-apps/opentmpfiles. If those are not in the runlevel then you would need to check the contents of /usr/lib/tmpfiles.d and (if needed) modify the initscript so that necessary files/directories are created, or in the case of sudo, eix, etc, then ignore and/or do whats needed via /etc/local.d ... all the while praising the gods of system improvement for making your system more robust :)

Thanks everyone for your help ...
virtual/tmpfiles-0 in package.provided it is

Ed: It is opentmpfiles which I wanted to avoid, this became clear as a result of the earlier posts in this thread.
I already had tmpfiles as part of openrc-0.13.11.
Adding virtual/tmpfiles-0 to package.provided is the right solution for me.
I have removed sudo from my local overlay and reverted to the main tree version.

Last edited by jonathan183 on Fri Sep 28, 2018 12:10 pm; edited 1 time in total

# This is a reimplementation of the systemd tmpfiles.d code
# Control creation, deletion, and cleaning of volatile and temporary files
#
# Copyright (c) 2012 Gentoo Foundation
# Released under the 2-clause BSD license.
#
# This instance is a pure-POSIX sh version, written by Robin H Johnson
# <robbat2@gentoo.org>, based on the Arch Linux version as of 2012/01/01:
# http://projects.archlinux.org/initscripts.git/tree/arch-tmpfiles
#
# See the tmpfiles.d manpage as well:
# https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
# This script should match the old manpage
# http://0pointer.de/public/systemd-man/tmpfiles.d.html
# as of 2012/03/12 and also implements some more recent features

Modern Linux distributions include a /run directory as a temporary filesystem (tmpfs) which stores volatile runtime data, following the FHS version 3.0. According to the FHS version 2.3, such data were stored in /var/run but this was a problem in some cases because this directory is not always available at early boot.

You see, it's a problem, your /var/run isn't availabe for volitle runtime data at early boot, and now we have /run (for "early boot") lets move all kinds of stuff there (like lockfiles, or what-have-you), and declare other stuffs under /var volitile, because it's obvious that because ... bwahhhahhhaaa. Having done that we now need a method of making sure that the necessary directory structure is now created, with the correct permissions, etc, ... see, much better, what could go wrong.

Anon-E-moose wrote:

If systemd does something stupid and the computer crashes and burns, does openrc have to follow suit?

Absolutely, the reasoning being that "gentoo follows upstream", anyone who doesn't see the sense in that is poo-pooing our fine work and can be dismissed as a "vocal minority".

Upstream is not forcing us to do this, it's Hubbs insane desire to make openrc look like systemd.
Since there are holdouts not wanting a systemd only distro, he's decided to slowly destroy it by making it look like the warmed over coprophilic pile called systemd.
That's all on Hubbs and should be a reason for his dismissal from power in gentoo._________________PRIME x570-pro, 3700x, RX 550 & 560
Acer E5-575 (laptop), i3-7100u - i965
---both---
5.5.18 zen kernel, gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon

My overlay ebuild http://dpaste.com/27WCY34
I cut off at 0.17 because that's where I decided to stop. Higher may work as well. Can anyone verify that the change was made at 0.23? In any case other stuff has been added along the way like automatically loading all modules. I'd really like to study all the openrc tarballs to see what really changed but i can't find them all.

Package.provided was a good idea but I think that it is planned to drop package.provided from portage in the near future.

No, it's not. "correctly" means that you will not suffer from silent breakage which is what you will get if the ebuilds and init scripts do not create the directories in the way the application expects it; this breakage will happen without tmpfiles. One can program manual fixes afterwards, once one sees what gets broken and why, but the OP asked how to avoid silent breakage. Putting virtual/tmpfiles into package.provided is a receipt for silent breakage.

Regardless of whether systemd's design was a good one, the reality is that notable programs have adopted its tmpfiles design and now depend on certain directories being available without being created by the application. Those directories are required to exist for proper functionality. To ensure their existence, your choices are:

Ensure the directories are stored on a filesystem that persists across reboots. Given the wide variance in Gentoo systems, ensuring this is hard. It becomes even worse when you consider that the system administrator may transplant a functioning system by way of bulk file copy, so it is not sufficient to ensure that, at package install time, the filesystem is persistent. The administrator may later rearrange to have some filesystem become non-persistent and not reinstall the package, so any hook in the ebuild would not be given a chance to reject the change.

Patch the application to generate the directories when needed. This would need to be done to every application that otherwise requires tmpfiles. It would need to be maintained across version upgrades. It may be difficult to do correctly in cases where upstream wants a root:root mode 1777 directory for unprivileged users to write into. Since the users are unprivileged, you cannot simply create the directory on first run. It needs to be pre-created by a privileged process, which upstream might not provide.

Create the directories at boot. This is the current tmpfiles approach. If you are going to go this path, it is far easier to have an implementation that can read systemd's tmpfiles format (ugly though it is), so that you can reuse the tmpfiles configuration files created and maintained by the upstream authors. If you invent your own configuration format, then you must maintain all the per-package configuration files yourself, including updating them as requirements change.

Given those choices, supporting tmpfiles is the path of least resistance.

I took it as a given that systemd is not a valid choice due to its many misfeatures and the general attitude of its developers across a variety of issues. With that choice ruled out, supporting tmpfiles is, in my opinion, the least trouble.

tmpfiles is by packages not only used for a correctly set up /run or /tmp, but tmpfiles.eclass is also used for a correct setup of files in some /var/* directories which on some systems might be temporary.

khayyam wrote:

[...] that is a misuse of the word(s) "correct[ly]", but we've been over this previously, so, again, when, and by what mysterious process, did these unnamed files in /var/* become "temporary"? ... that's a rhetorical question btw.

mv wrote:

No, it's not. "correctly" means that you will not suffer from silent breakage which is what you will get if the ebuilds and init scripts do not create the directories in the way the application expects it; this breakage will happen without tmpfiles. One can program manual fixes afterwards, once one sees what gets broken and why, but the OP asked how to avoid silent breakage. Putting virtual/tmpfiles into package.provided is a receipt for silent breakage.

mv ... here we are again with your selective quoting (corrected above) ... is it not perfectly clear that by harking back to that previous discussion I'm speaking to the question of technical correctness, and not how one now copes with these ill conceived changes? Prior to the introduction of this unnecessary volitility there was no silent breakage, or issue in need of a solution, and so "what you will get" is premised by "what was done" not "what you must do now".

Using package provided when one is using an older openrc that supports tmpfiles does not do away with tmpfile support it does away with the ebuild conflict, it will not cause silent breakage, at least as far as tmpfile support.

For those who don't understand please read the above several times till you do understand.

Edit to add: and if someone says "in the future they may change opentmpfiles and that would break older stuff"
yes, they might do that, in that case a patch could be made either against the already installed pieces /etc/init.d/tmpfiles* /etc/conf.d/tmpfiles* /lib/sh/rc/tmpfiles.sh or put into a patch file for the ebuild and re-emerge the older openrc.
6 of one half-dozen of the other.

ETA2: I did look at the difference between what's in openrc-0.13 and opentmpfile-0.1.3 and the init.d files differ in where the tmpfiles shell script is called from, but the options passed are exactly the same, other than location of shell script.
Opentmpfiles puts the tmpfiles shell script in /bin instead of /lib/rc/sh/ which is stupid, AFAIC, as it's not something that should be used indiscriminately, which it might be if left in /bin.
The tmpfiles shell script has been changed, mostly to add new options, for dry-run, etc. but overall it does the same things as tmpfiles.sh from <openrc-0.23._________________PRIME x570-pro, 3700x, RX 550 & 560
Acer E5-575 (laptop), i3-7100u - i965
---both---
5.5.18 zen kernel, gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon