Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

On Thu, 17 Nov 2016 15:07:32 -0500
Ian Stakenvicius <axs@g.o> wrote:

> On 17/11/16 02:42 PM, Michał Górny wrote:
> > 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?

The basic and most common functionality is creating files/dirs,
and ensuring permissions. The additional functionality includes writing
data to existing files (like procfs) and cleanups. However, the latter
can only be safely done at boot, so we're more focused on the former.

> > 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.

So do you expect all eix users to have to run an init script for eix to
be able to use it?

> > 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.

> > 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?

> > 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.

> 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.

So now I'm disallowed to run eix-update as a regular user because it
should be able to create its own directory that normally the packaging
should ensure?

> -----
>
> 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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>