On 17/11/16 03:50 PM, Michał Górny wrote: > On Thu, 17 Nov 2016 15:07:32 -0500 > Ian Stakenvicius <[email protected]> wrote: >> >> 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. > > So do you expect all eix users to have to run an init script for eix to > be able to use it? >
They already do -- said init script is called tmpfiles.setup and as you already know it's a requirement due to /var/cache/eix needing to be portage:portage and exist despite there not being a guarantee of /var/cache being preserved. >>> 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? > > Yes. That is, to have the temporary directories/files created and/or > permissions set without having to reboot your system. Or to do that > manually in the ebuild, when you're already installing a well-defined > file that explains how to do that. Right -- I presume that said file is usually being provided by upstream, rather than the package maintainer, though? Because there should be very few instances so far as I know that gentoo dev's would need to create tmpfiles.d *.conf files as part of their packaging efforts. >>> 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) > > You're missing the point. A purely minimal OpenRC-free system with no > volatile filesystems doesn't require any specific action at boot. It's > perfectly happy with the directories created by ebuild. Why would you > require the user of that system to install a tool he won't be using > anyway? When you say 'volatile filesystems' I assume then you're ignoring FHS paths where there are no persistence guarantees? Just because there's no tmpfs doesn't mean there's no volatility.. > >>> 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). > > Are you going to expect all packages with init scripts to depend > on OpenRC now, because your common-assumed use case requires the init > script to do something? Should we also make them depend on systemd at > the same time for completeness? And possibly on bash, vim, etc. so that > all those extra files get really used. > No. That would be unnecessary as there is, afaik, the requirement of SOME sort of init or rc system in @system already right? The thing is, in THIS case, OpenRC upstream is washing their hands of it. Which means, its up to the new package that actually -does- the processing to install an init script that calls itself (which makes sense) if openrc is booted. All fine and dandy except: #1, we should have something other than the end-user's @world to make sure this is installed (hence RDEPEND on it in packages that need it to be run) because openrc isn't apparently going to depend on it, #2 we need to somehow reconcile the fact that if systemd is installed despite openrc being booted, there still won't be any init scripts because the virtual won't bring in opentmpfiles. And #3, we need a clean way to make openrc actually start the init scripts when they're present and not start them when they're not, since openrc itself isn't carrying them. Now as i said before, i _am_ in agreement with you that all of this would be easier to just have integrated in openrc -- if openrc (the ebuild, not the upstream) RDEPENDs on the virtual and installs tmpfiles.dev and tmpfiles.setup init scripts that call either opentmpfiles or systemd-tmpfilesd, that would sweep all three of the above points under the rug and everything would work better than now. People using something other an init/rc system other than openrc and systemd aren't really supported anyways, so we can just leave it at that. >> ----- >> >> 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. > > It is the intention whenever the directory is volatile. In other words, > whenever Portage already spits a big QA warning that your keepdir is > not going to survive a reboot and/or cache cleanup. *nod* that makes sense. I assume most of these files are coming from upstream though right?
signature.asc
Description: OpenPGP digital signature
