On 17/11/16 02:42 PM, Michał Górny wrote: > On Thu, 17 Nov 2016 14:10:28 -0500 > Ian Stakenvicius wrote: > >> On 17/11/16 01:49 PM, Michał Górny wrote: >>> On Thu, 17 Nov 2016 19:46:41 +0100 >>> Michał Górny wrote: >>> >>>> On Thu, 17 Nov 2016 10:02:25 -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. >>>> >>>> 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. > Last I checked, tmpfiles.d *.conf filed did a whole lot more than just ensure missing directories are created. Has the functionality been stripped down to just that, now? > 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. OpenRC's init scripts all do that already, more or less. tmpfiles.d *.conf files are not used for this purpose -- definitely not by OpenRC, and most likely also not by upstream packages. > 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. I thought the reason for the eclass was so that when a package is installed, you don't need to reboot or otherwise trigger manually your system's tmpfiles.d processing to have it do the first-run process with the new *.conf file? > If someone is not using OpenRC or systemd, he doesn't need tmpfiles.d > implementation more than to run postinst. Sure he does. eix needs it to ensure files exist in /var/cache/ , for instance. dhcpd needs it to ensure /var/lib/dhcpd/dhcpd.leases exists and has the correct permissions. Neither of those has got anything to do with openrc's needs at boot time. Whether it's openrc or a fork of upstart or some strange busybox-only script or whatever init/rc system that's used, opentmpfiles provides the capability of processing these tmpfiles.d *.conf files and can be triggered at boot time to do it (or via cron, or with it being started as a daemon maybe later I presume) > 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? This would be because opentmpfiles is its own project now rather than something shipped as part of (or even needed by) openrc. And so, it's now a runtime dep *when and only when* not processing the tmpfiles.d *.conf file is going to make the package fail at runtime, internally and intrinsically to the package itself (not to its init script or any other init/rc related thing). Realistically, software should ensure the directories it needs at runtime are created through their own code, but upstreams are lazy and so they don't bother because, hey, we can have this tmpfiles.d *.conf file to have the system do it for us! In those cases, we'd need that rdepend. ----- Part of what you brought up here did trigger a bit of a concern for me though, and that is, we want to be careful that we as developers and package maintainers don't start using this eclass and tmpfiles.d *.conf files -instead of- keepdir. I'm hoping that this was never the intention, but in case it was I wanted to check.