On Thu, 17 Nov 2016 14:10:28 -0500 Ian Stakenvicius <[email protected]> wrote:
> 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. The package does not depend on functionality provided by tmpfiles.d. The package does depend on directory being created. Which was normally done via keepdir. However, then William changed /var/run to a symlink to /run. Now all packages that relied on keepdir need tmpfiles.d or some other magic to recreate the directories. The whole point of the eclass is to provide a reasonable way to combine both without having to do the same thing twice. That is, create the directory in postinst and install a tmpfiles.d entry to make it possible to recreate it on boot. If someone is not using OpenRC or systemd, he doesn't need tmpfiles.d implementation more than to run postinst. After postinst, the directory is created and the user is happy. However, if he uses OpenRC, then OpenRC will make sure the directory disappears on next boot. So why should ebuild add dependencies to solve a limitation caused by OpenRC? -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgpVg7EXVvZwO.pgp
Description: OpenPGP digital signature
