On Thu, Nov 17, 2016 at 07:49:07PM +0100, 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. I disagree. We mount a couple of things, /proc, /sys and /run off the top of my head, but that doesn't justify adding tmpfiles as an rdepend of OpenRC.
William
signature.asc
Description: Digital signature
