Re: [gentoo-dev] What's going on with the tmpfiles eclasses?

[Mike Gilbert]

On Tue, Apr 23, 2019 at 6:25 PM Zac Medico <zmedico@g.o> wrote:
>
> On 4/23/19 2:03 PM, Michael Orlitzky wrote:
> > We have two eclasses with almost-identical functions for handling
> > tmpfiles.d entries:
> >
> >   1. systemd.eclass
> >
> >      a. systemd_dotmpfilesd
> >      b. systemd_newtmpfilesd
> >      c. systemd_tmpfiles_create
> >
> >   2. tmpfiles.eclass
> >
> >      a. dotmpfiles
> >      b. newtmpfiles
> >      c. tmpfiles_process
> >
> > The do/new functions are basically identical, while the create/process
> > functions differ only in the fact that the one from tmpfiles.eclass
> > supports opentmpfiles as well. Why do we have both? Couldn't the
> > systemd.eclass ones be implemented in terms of the tmpfiles.eclass ones,
> > and then deprecated (in favor of tmpfiles.eclass itself) in newer EAPIs?
> >
> > Or am I missing something?
>
> Note that systemd.eclass is lighter on dependencies, which is why I
> chose it for the solution to bug 490676 [1] and bug 643386 [2] in the
> sys-apps/portage ebuilds.
>
> [1] https://bugs.gentoo.org/490676
> [2] https://bugs.gentoo.org/643386

Having reviewed bug 643386, I would certainly call Portage's use of
tmpfiles.d to be a "special case". There is no reason to depend on
virtual/tmpfiles or to call tmpfiles --create in pkg_postinst.

I don't think relying on the functions in systemd.eclass is a great
solution. A couple of alternatives I would propose:

1. Add a magic variable to tmpfiles.eclass to disable the RDEPEND for
packages that do not need to call tmpfiles --create on postinst or on
system boot.
2. Revert back to insinto /usr/lib/tmpfiles.d and doins to avoid using
tmpfiles.eclass or systemd.eclass.