From 7551c712d73f1d07f6dec2c9b8183a43204f4aa5 Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Sat, 24 Jan 2026 16:17:39 +0000 Subject: Rename "sub" to "prescription" --- doc/repodefs.html | 54 +++++++++++++++++++----------------------------------- 1 file changed, 19 insertions(+), 35 deletions(-) (limited to 'doc/repodefs.html') diff --git a/doc/repodefs.html b/doc/repodefs.html index 8a8a6a9..1f8fb6d 100644 --- a/doc/repodefs.html +++ b/doc/repodefs.html @@ -51,9 +51,7 @@ simply because they manage a repository of services.

Definitions

-
-

Store

-
+

Store

Store: place where service definitions are stored @@ -81,9 +79,7 @@ an administrator could be /etc/s6-rc/sources.

-
-

Repository

-
+

Repository

Repository: place in the filesystem where the repo commands work, @@ -118,9 +114,7 @@ instance, what non-root users would do in order to manage their own sets of services.

-
-

Reference database

-
+

Reference database

Reference database: the dependency graph between all the services @@ -140,9 +134,7 @@ the unions of all the stores is consistent: if not, the initialization fails, so the problem is reported as early as possible.

-
-

Set

-
+

Set

Set: a set of services with all the states the user wants them @@ -156,9 +148,8 @@ and what users will interact the most with. A set contains all the services defined in the reference database (so, each service listed in all the stores used by the repository) and associates, to each service, a given state that the user -wants this service to be in when the system boots. This target state is also -called a sub, because target states are implemented by -subdirectories of the directory holding a set. +wants this service to be in when the system boots. This target state is +called a prescription, or rx for shirt.

@@ -169,17 +160,15 @@ target states are reachable. When satisfied with the states, the user can commit the set, then install it.

-
-

Subs

-
+

Prescriptions

- Sub: the state the user wants a service to reach at boot time. + Prescription (or rx): the state the user wants a service to reach at boot time.

- A sub is the target state for every service in a set. At all times, -each service is in one and only one sub. The list of subs the service can be in + A prescription is the target state for every service in a set. At all times, +each service is in one and only one rx. The list of rxs the service can be in is the following:

@@ -187,7 +176,7 @@ is the following:
  • masked: when the set is committed, masked services will not be included in the compiled set database. They will be completely absent; if the set database is installed, s6-rc will not know them. -A service in another sub cannot depend on a masked service. Users typically mask +A service in another rx cannot depend on a masked service. Users typically mask services that are included in a store but are superfluous to them, services they just do not want to interact with.
  • disabled: these services will appear in the compiled set database, @@ -202,20 +191,18 @@ Other names for enabled are: active.
  • essential, aka always: these services have been marked as essential in their source definition directories, so they will always be enabled. They cannot be disabled or masked. They cannot depend on non-essential -services. This sub is typically used by early boot services that should always +services. This rx is typically used by early boot services that should always run.

    • - Working on a set basically means moving services from one of these subs to + Working on a set basically means moving services from one of these rxs to another, mostly choosing what services to enable or disable, and sometimes masking services the user does not want to see at all. Once the user is happy with a set, they should commit it.

    -
    -

    Commit

    -
    +

    Commit

    Committing a set means assembling a subset of all the source @@ -224,9 +211,7 @@ definition directories in the set and compiling them into a set. This set database can then be installed.

    -
    -

    Install

    -
    +

    Install

    Installing a committed set means copying the compiled set @@ -278,14 +263,14 @@ here.

  • Whenever the admin wants to customize their startup process:
      -
    • They can create new sets (with default subs coming from policy that's +
    • They can create new sets (with default prescriptions coming from policy that's hardcoded in the stores) with s6-rc-set-new, make a copy of an existing set with s6-rc-set-copy, or delete sets with s6-rc-set-delete.
    • They can list the existing sets with s6-rc-repo-list.
    • They can mask, unmask, enable or disable services in their favorite set with s6-rc-set-change.
      • -
    • They can check the list of services and their subs with +
    • They can check the list of services and their prescriptions with s6-rc-set-status.
    • They can check for inconsistencies and fix them with s6-rc-set-fix.
      • @@ -302,9 +287,8 @@ commands are involved.

    - Note that all these steps will be made easier in the near future by the higher-level -user interface provided by -s6-frontend. + All these steps can be done manually, but they are made easier by the higher-level +user interface provided by s6-frontend.

    -- cgit v1.3.1