On 17/11/16 12:22 PM, William Hubbs wrote: > On Thu, Nov 17, 2016 at 10:02:25AM -0500, Ian Stakenvicius wrote: >> On 17/11/16 01:03 AM, Michał Górny wrote: >>> On Wed, 16 Nov 2016 14:21:41 -0600 >>> William Hubbs wrote: >>> >>>> On Wed, Nov 16, 2016 at 01:04:11PM -0500, Ian Stakenvicius wrote: >>>>> On 16/11/16 12:03 PM, William Hubbs wrote: >>>>>> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote: >>>>>>> On 16/11/16 10:08 AM, William Hubbs wrote: >>>>>>>> opentmpfiles will be updated to install the service scripts which >>>>>>>> will be run when OpenRC boots a system. There is nothing for >>>>>>>> it to do if systemd is used to boot the system. >>>>>>>> >>>>>>>> William >>>>>>>> >>>>>>> >>>>>>> But there is something to do if openrc is used to boot the system and >>>>>>> systemd is the package providing tmpfiles.d processing via the virtual. >>>>>> >>>>>> The providers (opentmpfiles and systemd) will not block each other, so >>>>>> the only way this will happen is if you have openrc and systemd >>>>>> installed then forcefully remove opentmpfiles. I think you would not >>>>>> want to do that until you are ready to migrate to booting with systemd. >>>>>> >>>>>> William >>>>>> >>>>> >>>>> I think I'm having a hard time getting across the issue here...: >>>>> >>>>> 1 - we will have a virtual/tmpfiles that will bring in EITHER systemd, >>>>> or opentmpfiles. >>>>> >>>>> 2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles) >>>>> >>>>> 3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will >>>>> need to depend on virtual/tmpfiles in order to make sure that the >>>>> system has something installed that will process them at boot-time. >>>> >>>> Yes, this will be handled by an RDEPEND in the eclass. >>> >>> This is a wrong presumption. The eclass needs the virtual only for >>> pkg_postinst(). While RDEPEND is how we solve this now, it will no >>> longer be necessary in a future EAPI. >>> >> >> This makes sense to me as well -- which means every package that >> installs tmpfiles.d/ files should properly RDEPEND on the virtual on >> its own when the functionality arisen from those tmpfiles.d files is >> non-optional. > > Doesn't that bring into question the need of RDEPEND in the > eclass itself since it doesn't have a pkg_postinst function? I could > remove the rdepend from the eclass and add the following to the > documentation of the tmpfiles_process function: > > # Warning: Be sure that you rdepend on virtual/tmpfiles if you use this > # function in your ebuild. > > William > No I don't think so. The eclass uses these tmpfiles.d-processing commands in order to do its work, so therefore it needs to make sure the tools are there. As mgorny said earlier this RIGHT NOW means putting it in RDEPEND, but in a Future-EAPI it won't be RDEPEND but instead some other *DEPEND. Likewise, I don't think it's pertinent to inherit the eclass in order to ensure system runtime support of tmpfiles.d processing -- there's nothing to say that the eclass won't disappear in a year or two after all (because, say, the tmpfiles.d daemon starts using inotify and instantly processes any newly installed files, hypothetically)