On 17/11/16 01:49 PM, Michał Górny wrote: > On Thu, 17 Nov 2016 19:46:41 +0100 > Michał Górny <[email protected]> wrote: > >> On Thu, 17 Nov 2016 10:02:25 -0500 >> Ian Stakenvicius <[email protected]> wrote: >> >>> On 17/11/16 01:03 AM, Michał Górny wrote: >>>> On Wed, 16 Nov 2016 14:21:41 -0600 >>>> William Hubbs <[email protected]> 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. >> >> No, that's now what I meant. >> >> The eclass needs the virtual to create temporary directories once, >> in pkg_postinst(). Period. That's how far it is concerned. >> >> If user wants to use a volatile filesystem or any other more complete >> tmpfiles.d processing, he needs to use a init that supports that. Which >> means either OpenRC with tmpfiles or systemd. Ebuild has nothing to do >> with this. > > One more thing. I still believe openrc should RDEP on tmpfiles by > default since openrc is mounting a few standard locations > (like /var/run) as tmpfs by default. >
OpenRC isn't using tmpfiles.d *.conf files to do that (although it could). I didn't realize tmpfiles.d processing had any direct relationship or association with tmpfs mounts though (other than it helps solve the issue of files and dirs disappearing after reboots, of course). Part of the point of the virtual (and the reason for the init script arguments in this thread) is that it makes this functionality not tied to an init/rc system anymore -- that is: - systemd will just do it, if its used as init - systemd if installed can be used to do it from openrc/other-init - opentmpfiles can be used to do it from openrc/other-init The part where I see the ebuild coming into play here is for all of the packages that currently install .conf files into /usr/lib/tmpfiles.d/ (like apache, libvirt, etc. etc). If those packages are doing so explicitly because they non-optionally expect systemd-tmpfilesd or opentmpfiles to do what's been specified (and will fail otherwise), then this is an actual RDEPEND for those packages whether they use the eclass or not. You are right, though -- we avoid a whole bunch of this if openrc just RDEPENDs on the virtual and all other packages just assume there is support for tmpfiles.d processing in whatever init/rc system is used. However that seems to not be where things are going (at least from WilliamH's perspective)
signature.asc
Description: OpenPGP digital signature
