Hello, Laurent asked me in https://github.com/skarnet/s6-frontend/pull/2 to explain the intent behind my changes and why I think the current s6-frontend user mode is insufficient for it.
The use case I am trying to support is distribution packaging of per-user services. For example, a distribution should be able to ship s6-rc source definitions for PipeWire in packages, in a location shared by all users. An administrator should be able to provide local definitions or overrides, and an individual user should also be able to provide their own definitions. The repository and compiled database, on the other hand, are per-user state: different users may have different sets of services enabled. The actual spawning of a per-user service manager is a separate problem. For this I wrote: https://github.com/username13121/elogind-usersv It is essentially a generic spawner for a per-user service manager. The service manager is provided by a backend; for Artix I wrote an s6 backend: https://github.com/username13121/elogind-usersv-s6-backend-artix That backend knows the Artix-specific location of the user's compiled database and how to start the s6 supervision tree. I consider those paths and the lifetime of the user service manager to be distro/backend policy rather than something s6-frontend needs to handle. What is still needed is the management side: a convenient CLI for taking service definitions supplied by the distribution, administrator, and user, synchronizing a user's repository from those sources, and compiling the user's selected service set into an s6-rc database. s6-frontend already seems like the natural place for that. It provides the repository and set interfaces on top of the lower-level s6-rc commands, and it already has a `--user` mode. The part that is currently missing is a configurable source policy for user services. For system services, a distribution can configure `storelist` to point at shared service stores. This allows, for example, one store populated by packages and another containing administrator overrides. With `--user`, however, s6-frontend only defines a personal source store derived from the user's XDG/HOME directories. There is no independent list of shared user-service stores that a distribution can configure. Reusing the system `storelist` is not sufficient, because system services and user services are separate namespaces and a distribution may have completely different policies and paths for them. What I am proposing is therefore a separate configurable user-service profile. Conceptually, user mode needs: - a configurable list of shared user-service stores, for packages and administrator policy; - a personal source store under XDG_CONFIG_HOME, appended after the shared stores so that user definitions can override them; - a per-user repository and compiled database under XDG_STATE_HOME; - runtime state under XDG_RUNTIME_DIR; - configuration independent from the system-service profile. The particular directory names in my PR are only defaults. The shared store list, XDG subdirectories, and configuration-file names are build-time configurable. I used this in some experimental Artix packaging: https://github.com/username13121/s6-frontend-artix https://github.com/username13121/pipewire-s6-artix Artix already uses this system-service layout with s6-frontend: /etc/s6/sv /etc/s6/adminsv so its system configuration contains: storelist = /etc/s6/sv/:/etc/s6/adminsv For the user-service experiment I chose the analogous: /etc/s6/user/sv /etc/s6/user/adminsv and package the PipeWire user-service sources into the first store. The corresponding user configuration contains: storelist = /etc/s6/user/sv/:/etc/s6/user/adminsv s6-frontend then appends the invoking user's personal XDG source store to that list. Those `/etc/s6/user/...` paths are not intended as an Artix or s6 standard; they are just a packaging choice demonstrating that a distro can select its own layout. Likewise, the upstream defaults for the two configuration files are `/etc/s6.conf` and `/etc/s6-user.conf`, but Artix builds them as `/etc/s6-frontend.conf` and `/etc/s6-frontend-user.conf`. So the distinction I am trying to make is essentially: system profile: shared system stores -> system repository/database user profile: shared user stores + personal user store -> per-user repository/database while leaving the actual paths, and the mechanism that starts the per-user service manager, to the distribution. My PR also fixes a few inconsistencies between the documented user/XDG path policy and the implementation, and adds tests for the user profile and its path/configuration behavior. The main goal, though, is the separate user source policy: I would like a distribution to be able to package per-user service definitions and then use `s6 --user` itself to maintain each user's repository and compiled database, rather than having to provide another frontend around the lower-level s6-rc commands. Does this fit the intended scope of `s6 --user`, or is there another mechanism that is intended to handle shared, package-managed user service sources? Thanks, username13121
