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

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

[Michael Orlitzky]

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?

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

[Mike Gilbert]

On Tue, Apr 23, 2019 at 5:03 PM Michael Orlitzky <mjo@gentoo.org> 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?

Nope, seems like you have a pretty good handle on it. Just nobody has
gotten around to doing the work to deprecate the functions in
systemd.eclass.

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

[Zac Medico]

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

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
-- 
Thanks,
Zac


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

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

[Michael Orlitzky]

On 4/23/19 6:25 PM, Zac Medico wrote:
> 
> 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
> 

I think that's an illusion. The two eclasses should really have the same
dependencies because they do exactly the same thing.

Obviously we don't want to pull in systemd when people inherit the
systemd.eclass, so there are guards around every use of a systemd
program, such as

  systemd_reenable() {
    type systemctl &>/dev/null || return 0
    ...
  }

Likewise, the only function in tmpfiles.eclass that uses a systemd or
opentmpfiles program is

  tmpfiles_process() {
    ...
    if type systemd-tmpfiles &> /dev/null; then
      systemd-tmpfiles --create "$@"
    elif type tmpfiles &> /dev/null; then
      tmpfiles --create "$@"
    fi
    ...
  }

which will still work (albeit with a warning) if you somehow manage not
to have virtual/tmpfiles installed. So, if it's important, I think we
could drop the RDEPEND="virtual/tmpfiles" from tmpfiles.eclass.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On Wed, 2019-04-24 at 07:56 -0400, Michael Orlitzky wrote:
> Likewise, the only function in tmpfiles.eclass that uses a systemd or
> opentmpfiles program is
> 
>   tmpfiles_process() {
>     ...
>     if type systemd-tmpfiles &> /dev/null; then
>       systemd-tmpfiles --create "$@"
>     elif type tmpfiles &> /dev/null; then
>       tmpfiles --create "$@"
>     fi
>     ...
>   }
> 
> which will still work (albeit with a warning) if you somehow manage not
> to have virtual/tmpfiles installed. So, if it's important, I think we
> could drop the RDEPEND="virtual/tmpfiles" from tmpfiles.eclass.

Programs depend on tmpfiles being actually processed (either at install
time or on boot).  If you don't have the deps, you'll end up with
missing directories, and programs that don't work out of the box.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Michael Orlitzky]

On 4/24/19 8:24 AM, Michał Górny wrote:
>>
>> which will still work (albeit with a warning) if you somehow manage not
>> to have virtual/tmpfiles installed. So, if it's important, I think we
>> could drop the RDEPEND="virtual/tmpfiles" from tmpfiles.eclass.
> 
> Programs depend on tmpfiles being actually processed (either at install
> time or on boot).  If you don't have the deps, you'll end up with
> missing directories, and programs that don't work out of the box.
> 

I get where you're coming from, but then shouldn't systemd.eclass also
depend on systemd for its systemd-tmpfiles implementation? Otherwise,
you can make exactly the same argument about systemd_tmpfiles_create().

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On Wed, 2019-04-24 at 08:42 -0400, Michael Orlitzky wrote:
> On 4/24/19 8:24 AM, Michał Górny wrote:
> > > which will still work (albeit with a warning) if you somehow manage not
> > > to have virtual/tmpfiles installed. So, if it's important, I think we
> > > could drop the RDEPEND="virtual/tmpfiles" from tmpfiles.eclass.
> > 
> > Programs depend on tmpfiles being actually processed (either at install
> > time or on boot).  If you don't have the deps, you'll end up with
> > missing directories, and programs that don't work out of the box.
> > 
> 
> I get where you're coming from, but then shouldn't systemd.eclass also
> depend on systemd for its systemd-tmpfiles implementation? Otherwise,
> you can make exactly the same argument about systemd_tmpfiles_create().
> 

systemd.eclass has more than one purpose, and therefore such dep didn't
belong there (ebuilds should take care of the dependencies when using
tmpfiles logic from it).  tmpfiles.eclass on the other hand has a single
purpose, so we've solved the problem by adding an RDEPEND there.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Michael Orlitzky]

On 4/24/19 8:53 AM, Michał Górny wrote:
> 
> systemd.eclass has more than one purpose, and therefore such dep didn't
> belong there (ebuilds should take care of the dependencies when using
> tmpfiles logic from it).  tmpfiles.eclass on the other hand has a single
> purpose, so we've solved the problem by adding an RDEPEND there.
> 

I don't quite buy that either: do we assume that users will be running
either OpenRC or systemd?

If we do, then the RDEPEND on virtual/tmpfiles is redundant.

If we don't, then someone running (say) daemontools might want to
install a package that comes with a tmpfiles.d entry. Per our small file
policy, the tmpfiles.d entry should be installed unconditionally. And if
the tmpfiles entry needs to be processed immediately on OpenRC/systemd,
then tmpfiles_process() from tmpfiles.eclass must be used to support
OpenRC users. But, that will pull in virtual/tmpfiles unnecessarily on a
system that's running neither OpenRC nor systemd.

This is probably a "go away nobody cares" issue, but I'd prefer to
understand it first.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

On Thu, 2019-04-25 at 16:07 -0400, Michael Orlitzky wrote:
> On 4/24/19 8:53 AM, Michał Górny wrote:
> > systemd.eclass has more than one purpose, and therefore such dep didn't
> > belong there (ebuilds should take care of the dependencies when using
> > tmpfiles logic from it).  tmpfiles.eclass on the other hand has a single
> > purpose, so we've solved the problem by adding an RDEPEND there.
> > 
> 
> I don't quite buy that either: do we assume that users will be running
> either OpenRC or systemd?
> 
> If we do, then the RDEPEND on virtual/tmpfiles is redundant.
> 
> If we don't, then someone running (say) daemontools might want to
> install a package that comes with a tmpfiles.d entry. Per our small file
> policy, the tmpfiles.d entry should be installed unconditionally. And if
> the tmpfiles entry needs to be processed immediately on OpenRC/systemd,
> then tmpfiles_process() from tmpfiles.eclass must be used to support
> OpenRC users. But, that will pull in virtual/tmpfiles unnecessarily on a
> system that's running neither OpenRC nor systemd.
> 

Wrong.  tmpfiles_process() requires virtual/tmpfiles on any system,
including daemontools, bare minimal init and whatever.  Keeping it
installed afterwards is a minor side effect, and technical limitation of
our dependency types (lack of install-depend).

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Michael Orlitzky]

On 4/25/19 4:20 PM, Michał Górny wrote:
> 
> Wrong.  tmpfiles_process() requires virtual/tmpfiles on any system,
> including daemontools, bare minimal init and whatever.  Keeping it
> installed afterwards is a minor side effect, and technical limitation of
> our dependency types (lack of install-depend).
> 

What's wrong? You only need the effect of tmpfiles_process() if you're
running systemd or OpenRC. If the user is running SysV-init and if the
package also installs a SysV-init script, then that init script is going
to have to create any temporary directories it needs, because SysV-init
doesn't know anything about tmpfiles.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On Thu, 2019-04-25 at 16:49 -0400, Michael Orlitzky wrote:
> On 4/25/19 4:20 PM, Michał Górny wrote:
> > Wrong.  tmpfiles_process() requires virtual/tmpfiles on any system,
> > including daemontools, bare minimal init and whatever.  Keeping it
> > installed afterwards is a minor side effect, and technical limitation of
> > our dependency types (lack of install-depend).
> > 
> 
> What's wrong? You only need the effect of tmpfiles_process() if you're
> running systemd or OpenRC. If the user is running SysV-init and if the
> package also installs a SysV-init script, then that init script is going
> to have to create any temporary directories it needs, because SysV-init
> doesn't know anything about tmpfiles.
> 

This isn't about init scripts.  This is about arbitrary directories that
need to be created at runtime and potentially cleaned up or recreated
after reboot, such as cache directories.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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@gentoo.org> 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.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

On Thu, 2019-04-25 at 17:24 -0400, Mike Gilbert wrote:
> On Tue, Apr 23, 2019 at 6:25 PM Zac Medico <zmedico@gentoo.org> 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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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@gentoo.org> 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@gentoo.org> 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.

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

[Michael Orlitzky]

On 4/25/19 5:23 PM, Michał Górny wrote:
>>
>> What's wrong? You only need the effect of tmpfiles_process() if you're
>> running systemd or OpenRC. If the user is running SysV-init and if the
>> package also installs a SysV-init script, then that init script is going
>> to have to create any temporary directories it needs, because SysV-init
>> doesn't know anything about tmpfiles.
>>
> 
> This isn't about init scripts.  This is about arbitrary directories that
> need to be created at runtime and potentially cleaned up or recreated
> after reboot, such as cache directories.
> 

It's very much about init scripts. We have at least five service
managers in the tree,

  * sys-apps/openrc
  * sys-apps/systemd
  * sys-apps/sysvinit
  * sys-process/runit
  * sys-process/daemontools(-encore)

And the only reason we would need a transient directory created and/or
cleaned-up is because one of those service managers is going to start a
program that needs it. Two of them can use the tmpfiles mechanism, but
the others must handle it on their own: in particular, they don't need
tmpfiles_process() to do anything.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

On Thu, 2019-04-25 at 17:42 -0400, Michael Orlitzky wrote:
> On 4/25/19 5:23 PM, Michał Górny wrote:
> > > What's wrong? You only need the effect of tmpfiles_process() if you're
> > > running systemd or OpenRC. If the user is running SysV-init and if the
> > > package also installs a SysV-init script, then that init script is going
> > > to have to create any temporary directories it needs, because SysV-init
> > > doesn't know anything about tmpfiles.
> > > 
> > 
> > This isn't about init scripts.  This is about arbitrary directories that
> > need to be created at runtime and potentially cleaned up or recreated
> > after reboot, such as cache directories.
> > 
> 
> It's very much about init scripts. We have at least five service
> managers in the tree,
> 
>   * sys-apps/openrc
>   * sys-apps/systemd
>   * sys-apps/sysvinit
>   * sys-process/runit
>   * sys-process/daemontools(-encore)
> 
> And the only reason we would need a transient directory created and/or
> cleaned-up is because one of those service managers is going to start a
> program that needs it. Two of them can use the tmpfiles mechanism, but
> the others must handle it on their own: in particular, they don't need
> tmpfiles_process() to do anything.
> 

No.  tmpfiles is also used for programs started directly by user, such
as eix.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Michael Orlitzky]

On 4/26/19 12:53 AM, Michał Górny wrote:
>>
>> And the only reason we would need a transient directory created and/or
>> cleaned-up is because one of those service managers is going to start a
>> program that needs it. Two of them can use the tmpfiles mechanism, but
>> the others must handle it on their own: in particular, they don't need
>> tmpfiles_process() to do anything.
>>
> 
> No.  tmpfiles is also used for programs started directly by user, such
> as eix.
> 

Good example. Does eix work on a machine running something other than
systemd or OpenRC? I don't think so -- not if it needs that tmpfiles
entry to be processed every reboot. Thus it should have its own RDEPEND
on virtual/tmpfiles, making the one in the eclass redundant.

I suspect the same is true of any other example. Let's get to the point:
is there a single example of a package that works with runit, sysvinit,
or daemontools but which needs tmpfiles_process() to run?

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

[Michael Orlitzky]

On 4/26/19 7:07 AM, Michael Orlitzky wrote:
> Thus it should have its own RDEPEND on virtual/tmpfiles, making the
> one in the eclass redundant.
Correction, it should RDEPEND on either systemd or OpenRC. Having the
"tmpfiles" binary installed is not enough; it needs to be run every
reboot. The RDEPEND in the eclass is still redundant, though.

Re: [gentoo-dev] OT: persistence of directories under /var/cache

[Michael Orlitzky]

On 4/26/19 12:53 AM, Michał Górny wrote:
> 
> No.  tmpfiles is also used for programs started directly by user, such
> as eix.
> 

This configuration is buggy to begin with: if I run eix-update as my
user, then the permissions on the files it creates under /var/cache/eix
are wrong (mjo:mjo, mode 664). If I run eix as root and it drops
privileges, then the permissions on the files it creates are correct
(portage:portage, mode 664). But when I run eix as root, eix can create
/var/cache/eix itself! It doesn't need the tmpfiles entry in the
scenario that works. Maybe a setgid bit could make sense of things, but
the simplest solution is probably best: a per-user cache.

Regardless of the particulars of eix, I'm a lot skeptical of treating
directories under /var/cache as temporary in the first place. It leads
to problems just like this one, where a non-root process can't be sure
that its cache directory will exist and have the correct permissions. In
this case we've solved the problem by requiring either OpenRC or
systemd, but that's not a good answer.

We would be much better off if the ebuild could create that directory
with the correct permissions once, and know that it will persist. The
FHS is ambiguous here:

  https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05.html

It calls out files specifically,

  Files located under /var/cache may be expired in an application
  specific manner, by the system administrator, or both. The application
  must always be able to recover from manual deletion of these files
  (generally because of a disk space shortage). No other requirements
  are made on the data format of the cache directories.

The fact that we can't track the directory /var/cache/eix without a file
at /var/cache/eix/.keep is something else to worry about, but that's a
problem we've caused ourselves and one worth ignoring if it saves us
enough trouble.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

On Fri, 2019-04-26 at 07:07 -0400, Michael Orlitzky wrote:
> On 4/26/19 12:53 AM, Michał Górny wrote:
> > > And the only reason we would need a transient directory created and/or
> > > cleaned-up is because one of those service managers is going to start a
> > > program that needs it. Two of them can use the tmpfiles mechanism, but
> > > the others must handle it on their own: in particular, they don't need
> > > tmpfiles_process() to do anything.
> > > 
> > 
> > No.  tmpfiles is also used for programs started directly by user, such
> > as eix.
> > 
> 
> Good example. Does eix work on a machine running something other than
> systemd or OpenRC?

Yes, it does.

>  I don't think so -- not if it needs that tmpfiles
> entry to be processed every reboot. Thus it should have its own RDEPEND
> on virtual/tmpfiles, making the one in the eclass redundant.

It doesn't need to be processed every reboot.  It needs to be processed
at least once.  Now, if you were doing something fancy like having
/var/cache on tmpfs, then it would need to be processed on reboot.

> 
> I suspect the same is true of any other example. Let's get to the point:
> is there a single example of a package that works with runit, sysvinit,
> or daemontools but which needs tmpfiles_process() to run?

The general assumption we made here is that if you use OpenRC
or systemd, you may have fancy stuff like /tmp on tmpfs, and you want
tmpfiles processing running every reboot.  If you don't, we assume you
need to run it at least once, to get the directories initialized.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Michael Orlitzky]

On 4/26/19 9:07 AM, Michał Górny wrote:
> 
>>  I don't think so -- not if it needs that tmpfiles
>> entry to be processed every reboot. Thus it should have its own RDEPEND
>> on virtual/tmpfiles, making the one in the eclass redundant.
> 
> It doesn't need to be processed every reboot.  It needs to be processed
> at least once.  Now, if you were doing something fancy like having
> /var/cache on tmpfs, then it would need to be processed on reboot.
> 

If /var/cache/eix can be deleted, then the tmpfiles entry needs to be
processed on every reboot. If /var/cache/eix cannot be deleted, then a
tmpfiles entry is the wrong way to create it: keepdir should be used
instead.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Fri, 2019-04-26 at 09:24 -0400, Michael Orlitzky wrote:
> On 4/26/19 9:07 AM, Michał Górny wrote:
> > >  I don't think so -- not if it needs that tmpfiles
> > > entry to be processed every reboot. Thus it should have its own RDEPEND
> > > on virtual/tmpfiles, making the one in the eclass redundant.
> > 
> > It doesn't need to be processed every reboot.  It needs to be processed
> > at least once.  Now, if you were doing something fancy like having
> > /var/cache on tmpfs, then it would need to be processed on reboot.
> > 
> 
> If /var/cache/eix can be deleted, then the tmpfiles entry needs to be
> processed on every reboot. If /var/cache/eix cannot be deleted, then a
> tmpfiles entry is the wrong way to create it: keepdir should be used
> instead.

Whether it can be deleted is up to system's configuration.  The current
solution works for majority of cases, including a. people who use
systemd or OpenRC, and set their systems to clean it up, and b. people
who don't use either but don't clean it up.

We can't support everyone, and a small potential minority for whose this
might not work is no excuse to replace it with a worse solution.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Michael Orlitzky]

On 4/26/19 9:32 AM, Michał Górny wrote:
> 
> Whether it can be deleted is up to system's configuration.  The current
> solution works for majority of cases, including a. people who use
> systemd or OpenRC, and set their systems to clean it up, and b. people
> who don't use either but don't clean it up.
> 
> We can't support everyone, and a small potential minority for whose this
> might not work is no excuse to replace it with a worse solution.
> 

https://www.youtube.com/watch?v=yjfrJzdx7DA

I don't believe that one of the world's foremost experts on package
management is stumped trying to configure a common cache directory. But,
I've let you change the subject.

We're only talking about eix because you gave it as an example of a
package that needs the RDEPEND=virtual/tmpfiles in the eclass, claiming
that it needs tmpfiles_process() to work. Yet you've acknowledged that
this is an eix-specific hack that won't work in some cases.

In cases like that, adding RDEPEND=virtual/tmpfiles to the ebuild is a
better solution, because (a) the end result is exactly the same, (b) it
keeps the dependency out of the eclass, and (c) it localizes the
dependency to the place that needs it, namely the wacky package.

In cases like that, using a simple "dodir /var/cache/eix" is a better
solution because (a) the end result is exactly the same, (b) it keeps
the dependency out of the eclass, and (c) doesn't need a dependency on
virtual/tmpfiles at all.

Both are preferable in the case of app-portage/eix, so I don't buy it as
justification for keeping the RDEPEND in the eclass. Are there better
examples?

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2854 bytes --]

On Fri, 2019-04-26 at 10:26 -0400, Michael Orlitzky wrote:
> On 4/26/19 9:32 AM, Michał Górny wrote:
> > Whether it can be deleted is up to system's configuration.  The current
> > solution works for majority of cases, including a. people who use
> > systemd or OpenRC, and set their systems to clean it up, and b. people
> > who don't use either but don't clean it up.
> > 
> > We can't support everyone, and a small potential minority for whose this
> > might not work is no excuse to replace it with a worse solution.
> > 
> 
> https://www.youtube.com/watch?v=yjfrJzdx7DA
> 
> I don't believe that one of the world's foremost experts on package
> management is stumped trying to configure a common cache directory. But,
> I've let you change the subject.
> 
> We're only talking about eix because you gave it as an example of a
> package that needs the RDEPEND=virtual/tmpfiles in the eclass, claiming
> that it needs tmpfiles_process() to work. Yet you've acknowledged that
> this is an eix-specific hack that won't work in some cases.
> 
> In cases like that, adding RDEPEND=virtual/tmpfiles to the ebuild is a
> better solution, because (a) the end result is exactly the same, (b) it
> keeps the dependency out of the eclass, and (c) it localizes the
> dependency to the place that needs it, namely the wacky package.

Maybe.  However, as I already said, we have determined that (a) it is
easier for devs to have the dep in eclass, and (b) it doesn't hurt.  If
you are really a tmpfiles hater, you can use package.provided and stop
harming users through being absurdly pedantic.

> In cases like that, using a simple "dodir /var/cache/eix" is a better
> solution because (a) the end result is exactly the same, (b) it keeps
> the dependency out of the eclass, and (c) doesn't need a dependency on
> virtual/tmpfiles at all.

No, it isn't 'exactly the same'.  (a) it doesn't set correct
permissions, and (b) it requires you to reinstall the package every time
the directory might disappear.

> Both are preferable in the case of app-portage/eix, so I don't buy it as
> justification for keeping the RDEPEND in the eclass. Are there better
> examples?

I'm sorry but this is getting silly.  I've provided you with
the rationale and with an example.  I'm not going to spend half of the
day trying to throw more and more examples, so that you'd keep rejecting
them, and in the end claim that I haven't provided any justification
because you rejected everything.

The data you have should be entirely sufficient to understand how things
work.  If you disagree with it, that's your right.  However, your weak
counter-arguments aren't going to convince me, and I don't see any
purpose in bringing more arguments because I really do see where this
is going.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Michael Orlitzky]

On 4/26/19 10:54 AM, Michał Górny wrote:
>>
>> In cases like that, adding RDEPEND=virtual/tmpfiles to the ebuild is a
>> better solution, because (a) the end result is exactly the same, (b) it
>> keeps the dependency out of the eclass, and (c) it localizes the
>> dependency to the place that needs it, namely the wacky package.
> 
> Maybe.  However, as I already said, we have determined that (a) it is
> easier for devs to have the dep in eclass, and (b) it doesn't hurt.  If
> you are really a tmpfiles hater, you can use package.provided and stop
> harming users through being absurdly pedantic.
> 

This isn't about hating tmpfiles. In my original message, I asked why we 
couldn't replace the systemd_* implementations with the ones from 
tmpfiles.eclass. Apparently there's only one reason, given by Zac: the 
extraneous RDEPEND in the tmpfiles eclass. My goal here is to clean up 
our eclasses, not complain about tmpfiles.

Ease of use is irrelevant if the dependency is wrong, and "it doesn't 
hurt" is clearly false because it's preventing us from deleting a bunch 
of copy/pasted code.


>> In cases like that, using a simple "dodir /var/cache/eix" is a better
>> solution because (a) the end result is exactly the same, (b) it keeps
>> the dependency out of the eclass, and (c) doesn't need a dependency on
>> virtual/tmpfiles at all.
> 
> No, it isn't 'exactly the same'.  (a) it doesn't set correct
> permissions,

An irrelevant detail. Set them to whatever you like in the ebuild.


> and (b) it requires you to reinstall the package every time
> the directory might disappear.

That's how it works now.