[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
From:       Mike Gilbert <floppym () gentoo ! org>
Date:       2020-11-30 21:56:16
Message-ID: CAJ0EP40t4+M_U0Kq2JGHKqM0h5uRkO0Vx=mj8pE2SnXCnRMyDA () mail ! gmail ! com
[Download RAW message or body]

On Sun, Nov 29, 2020 at 4:50 PM William Hubbs <williamh@gentoo.org> wrote:
>
> On Thu, Nov 26, 2020 at 07:55:33AM +0100, Piotr Karbowski wrote:
> > Hi,
> >
> > On 25/11/2020 22.57, Georgy Yakovlev wrote:
> > > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus,
> > > and is just a drop-in replacement, the only step needed is to emerge the
> > > package.
> > > it's a simple single binary + manpage, binary links to libacl and couple other
> > > system libs.
> >
> > Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been
> > using it since end of October.
> >
> > Two things that are different in terms of interface to opentmpfiles is
> > that systemd-tmpfiles does not have --dry-run runtime option, and it
> > will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of
> > /run, but that's just an warning.
>
> Also, have we tested this on musl systems?
>
> My plan is to take the tmpfiles code from systemd, like eudev and elogin
> have done, and rewrite it to not use the systemd libraries so it will be
> more portable.

I think this is a bigger task than you realize. Even if you manage to
get an initial rewrite done, you would also need to keep up with
feature updates systemd releases. That hasn't worked out for eudev,
and I doubt it would work out for this yet-to-exist tmpfiles project.

Maintaining a patchset against the systemd sources is probably the
best path forward on this.

[prev in list] [next in list] [prev in thread] [next in thread]