I think the second option is the right one: `/etc/s6-user.conf`
should be shared by all users and needs a layer of XDG interpretation.
Yes, that is reasonable. I will add an XDG interpretation layer.
I disagree with removing --user flag. I think instance selection
should stay explicit:
Right, the --user flag should remain, and there should also be an
explicit --system flag to choose the opposite. The question still
remains: what should the default be?
My position is still that "s6 --system" should be the default for
root, because the common case when making service manager calls as root
is that you want to address the system one, and "s6 --user" should be
the default for non-root, because the common case is you want to address
your own user services. Most "s6 --system" calls would be unavailable
to users anyway for lack of permission; but it would still be possible
for a user to "s6 --system live status", for instance, to read the
state of the current system services.
I don't think the login environment should silently change what plain
`s6` means.
I'm thinking more effective uid than login environment.
$ s6 status
-> user profile selector was lost
-> silently loads system configuration
That is why. The effective uid is a more reliable marker. And
--system or --user could be used to override that autodetection anyway.
So I think one explicit `--user` flag is simpler than making plain `s6`
context-dependent and then needing a second `--system` mechanism to
escape that context.
I disagree. Adding a --system option is simple, and it is the better
choice if it allows users to have access to the shorter command in the
common case.
For the same reason, I do not think `user=1` is necessary.
The suggested 'user=1' is only internal API happening between the 's6'
command, which selects and reads the config file, and the 's6-frontend'
command, which does the actual work. It does not appear in the user's
environment. It is not visible anywhere except the s6-frontend code.
The current PR deliberately avoids making `/etc/s6-user.conf`
XDG-aware. Because of that, I added compiled defaults such as:
--user-conffile=/etc/s6-user.conf
--with-user-store-list=/usr/share/s6/user/sources:/etc/s6/user/sources
--with-user-source-subdir=/s6/sources
--with-user-repo-subdir=/s6-rc/repository
--with-user-bootdb-subdir=/s6-rc/compiled/current
These are more complex than necessary, and I don't think I could, or
would want to, merge these changes anyway: see below.
The config should be interpretable, and the compiled values should just
remain defaults.
This is reasonable, it will just require a little more effort; I'll be
on it as soon as I can.
A user may eventually want to create their own user-profile override
under `XDG_CONFIG_HOME`.
That is addressed by the S6_CONF environment variable. A user who wants
to override their configuration is always free to do so by setting that
variable. I should probably make it S6_USER_CONF for this case, since
S6_CONF would override the system defaults, not the user ones.
Now.
This was a useful exchange, because it clarified what I need to
improve for proper user service support.
However, the mail I answered to appears very likely to have been
generated by an LLM.
You may have a good reason for this: for instance, if you're not
fluent in English and you asked an LLM to translate. But it does not
look that way. The arguments themselves seem to have come from the
LLM's "reasoning", and parts of the suggested changes (at least the
new configure options) seem directly LLM-generated. This is a violation
of the contributor policy:
https://git.skarnet.org/cgit/s6-frontend/tree/CONTRIBUTING
Also, when I said I wanted a design discussion, I meant, and let me
make this very clear and explicit, a design discussion _between humans_.
I wish to have input from the community, not from what you can extrude
from an aggregate of unethically sourced data.
As a consequence:
- I am closing the PR.
- I am keeping the discussion open in cases you, as a human being, or
other members of the community, want to participate.
- If you are using an LLM to participate, you are expected to disclose
it and to give your reasons for it.
- Any failure to disclose, or any insufficient reason (as decided by
me,
this is not a democratic process) will result in a ban.
Please help me keep this space slop-free, and a place where we can
build
untainted future technology. (This is not an invitation to discuss
merits and demerits of LLMs on the list. If you feel the need to do so,
do so somewhere else.)
--
Laurent
