1 |
On Sun, Nov 29, 2020 at 4:50 PM William Hubbs <williamh@g.o> wrote: |
2 |
> |
3 |
> On Thu, Nov 26, 2020 at 07:55:33AM +0100, Piotr Karbowski wrote: |
4 |
> > Hi, |
5 |
> > |
6 |
> > On 25/11/2020 22.57, Georgy Yakovlev wrote: |
7 |
> > > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus, |
8 |
> > > and is just a drop-in replacement, the only step needed is to emerge the |
9 |
> > > package. |
10 |
> > > it's a simple single binary + manpage, binary links to libacl and couple other |
11 |
> > > system libs. |
12 |
> > |
13 |
> > Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been |
14 |
> > using it since end of October. |
15 |
> > |
16 |
> > Two things that are different in terms of interface to opentmpfiles is |
17 |
> > that systemd-tmpfiles does not have --dry-run runtime option, and it |
18 |
> > will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of |
19 |
> > /run, but that's just an warning. |
20 |
> |
21 |
> Also, have we tested this on musl systems? |
22 |
> |
23 |
> My plan is to take the tmpfiles code from systemd, like eudev and elogin |
24 |
> have done, and rewrite it to not use the systemd libraries so it will be |
25 |
> more portable. |
26 |
|
27 |
I think this is a bigger task than you realize. Even if you manage to |
28 |
get an initial rewrite done, you would also need to keep up with |
29 |
feature updates systemd releases. That hasn't worked out for eudev, |
30 |
and I doubt it would work out for this yet-to-exist tmpfiles project. |
31 |
|
32 |
Maintaining a patchset against the systemd sources is probably the |
33 |
best path forward on this. |