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

[Mike Gilbert]

On Thu, Apr 25, 2019 at 5:26 PM Michał Górny <mgorny@g.o> wrote:
>
> 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.

4. Drop the dependency from tmpfiles.eclass given that
sys-apps/systemd or sys-apps/openrc will bring it in anyway.