As a solution for bug #605368, tmpfiles.eclass was recommended. But it seems that it can not be used on current stable systems with OpenRC. Current stable OpenRC is 0.22.4 tmpfiles.eclass adds dependency on virtual/tmpfiles, which is currently unstable, but that's not a problem, let's unmask it. What's happens next? It pulls either sys-apps/opentmpfiles or sys-apps/systemd. We have OpenRC system, so we go for the first one... No, just look at sys-apps/opentmpfiles and we will see: RDEPEND="!<sys-apps/openrc-0.23" Which is fine, because it's new mechanism, that was split from openrc package in bug #599044. So, user should update openrc to unstable, which could be not what he wants. This is not a major issue(as virtual dependency is already unstable, the whole eclass can be for unstable only systems), but apparently, it is the blocker for bug #605368, unless other solution for it can be achieved(for example - manual reimplementing directory creation in pkg_postinst for some ebuilds). Or we just could wait for openrc >0.23 to become stable :-) Bug was filed by mgorny's request as a 'reminder'
Since it is quite a major change and 'just' a QA warning being fixed, I believe it would be reasonable to revbump to ~arch and have the new revision stabilized in its own time. Also, the reminder part was about the dependency being used on Linux only which defeats its purpose.
OpenRC 0.23 is stable now, closing this as FIXED
