(I am extremely sorry for delaying this mail so much. I have just done
two major refactoring/overhaul projects in this vacation around the
Spring Festival, and still have one remaining. These projects are a
part of my formal occupation, but I would not have much low-distraction
time best for
The s6-svperms is a great feature but it only handle permissions control of a
service at runtime. That means that we need to change the permissions of the
service everytime that a reboot occurs.
For a server, this is not really a big deal but for a desktop machine this can
be really hard to
Services can fix their own permissions so if s6-rc is going to grow that
functionality it should be in the generated run, not in some rarely used
outboard helper service.
As answered on IRC, for ML completeness: no, because permissions should
be fixed when the supervisor starts, not when the
On Mon, Feb 15, 2021 at 11:58:59AM +, Laurent Bercot wrote:
> > So, If we have a e.g /data/perms/rules/uid//allow file and if
> > s6-supervise check this directory at the creation time and create the
> > necessary file/directory with the respective uid/gid found at that
> > directory, we
I do not really understand their excuse here. CLI incompatibility is
trivially solvable by creating links (or so) for `halt' / `poweroff' /
`reboot', and even the `shutdown' command can be a wrapper for an `atd'
based mechanism.
The options! The options need to be all compatible. :) And
(Apologies for the broken threading, I originally sent my answer with
the incorrect From: and it was rightfully rejected.)
