Re: [gentoo-dev] [PATCH 1/3] tmpfiles.eclass: Support using on non-Linux systems

[Michał Górny]

On wto, 2017-05-02 at 09:38 -0500, William Hubbs wrote:
> On Sun, Apr 30, 2017 at 09:06:53PM +0200, Michał Górny wrote:
> > Fix the eclass code to remove the misguided Linux conditionals.
> > The whole purpose of the eclass was to avoid having to implement
> > fallback logic for systems not having service manager tmpfiles.d
> > support. Making it conditional to Linux implied that for non-Linux
> > systems (Prefix, FreeBSD) we would have to implement explicit fallback
> > to create the necessary directories.
> >
> > While systemd (and therefore systemd-tmpfilesd) is indeed
> > Linux-specific, the opentmpfiles implementation should be pretty
> > portable and there is no reason to restrict it to Linux only, or to
> > prevent using it on non-Linux OpenRC (and non-OpenRC) systems.
>
> Opentmpfiles can run right now on non-openrc systems, but it requires a
> linux host; that is why the Linux conditionals are there. We currently support
> selinux and even more specific linux code is coming with the btrfs
> subvolume support.

It's funny because I've just got a confirmation that it works
on FreeBSD.

> The purpose of opentmpfiles is to provide a non-systemd program that
> mirrors the behavior of systemd-tmpfiles so that Linux users do not have
> to install systemd, but there are features that definitely would not
> work on other hosts.

We need a tool that works for everyone. Not excuses not to support Linux
just because systemd does not.

> Also, the tmpfiles.d standard doesn't allow tmpfiles to do things based
> on operating systems,

And what's the problem with installing tmpfiles.d files aligned to
the operating system in question? After all, you don't tell everyone not
to use OpenRC outside Linux just because someone might have put Linux-
specific paths in the init.d file.

> and the configuration search paths (particularly
> /run/tmpfiles.d and the non-support of /lib/tmpfiles.d) are linux specific.
>

Does that hurt anyone? We're talking about Gentoo/FBSD and Gentoo
Prefix, i.e. Gentoo-flavored systems which we have control over. If you
really insist, I can ask our FBSD/Prefix teams to look through the code
and make sure that it works across all interesting platforms.

-- 
Best regards,
Michał Górny