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

[Michał Górny]

On Thu, 2019-04-25 at 17:24 -0400, Mike Gilbert wrote:
> 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.
>

3. Just live with the extra dependency given that some other package
will probably bring it anyway.

-- 
Best regards,
Michał Górny