I finally could take the time to read everything with attention. Thank
you for this detailed explanation!
I agree with more or less all your points. Here is where I'm coming
from:
- "User services" are not yet a thing in the s6 ecosystem: the precise
definition of what they do, and a fortiori how they're implemented, is
very distro-dependent and it's difficult to program mechanisms that are
usable for any distro without hardcoding policy. Consequently, it is
expected that distributions would helm the efforts to add user services
to s6, and your proposition is exactly the kind of thing I expected (and
was hoping for).
- The existing mechanisms are very much placeholders and subject to
heavy modifications as long as we can design something good and
cohesive.
- You are right in identifying s6-frontend, the s6 command, as the
place to handle distribution packaging of user services.
- In my view, ideally, users would have their own s6.conf
configuration file that defines all the relevant variables for its user;
the location file would typically be in the user environment, set at
login time. This way, users could just use "s6" instead of "s6 -u",
which
I think is a better UI. A few people convinced me that having a --user
flag was a good thing, e.g. for testing, or if root has its personal
user services; that's why I added the flag. Ultimately though, I think
having "s6" automatically pick up the relevant user configuration file
by default makes for a better experience, and I would like it to be the
normal case, if at all possible.
- I am totally open to rewriting the --user option, in particular
override priority, if necessary. Things are absolutely not set in stone
here.
- I myself do not use user services (or any login manager of any kind)
so I would very much like participation from people who do.
So my first questions would be:
- Is it reasonable to expect a distro to install a fully functional,
fully expanded (i.e. no need to interpret XDG variables) configuration
file at user creation time, and to automatically set an environment
variable in the user's login shell to that configuration file? If it's
not, it means that /etc/s6-user.conf, as you have named it, needs a
layer of interpretation so that the XDG variables expand to the correct
value. It is doable; it just means a little more effort.
- More generally, what needs to be the default set by the system,
and what needs to be overridable by the user and to what extent?
- If the configuration file remains the unique entry point, I can
probably remove the --user flag entirely by checking a user=1 variable
that user configuration files would set. That would allow XDG processing
in s6-frontend itself rather than duplicating it in the layer that reads
the config file.
What do you (plural) think?
--
Laurent
