Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius <axs@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 6182 bytes --]

On 17/11/16 03:50 PM, Michał Górny wrote:
> On Thu, 17 Nov 2016 15:07:32 -0500
> Ian Stakenvicius <axs@gentoo.org> 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?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]