now it needs the -F to be populated with defaults, right?
not correct
Any chance I copied the previously existing into .boot-user@ ... or one of the interim 0.6.0 versions did and created havoc?
see below
The problem as I see it is that in this rare (maybe) case if a module can't be created 66-env doesn't work
Normal. If the 66-enable fail, the service is not enabled at all, so no configuration file to handle.
So if you edit this and add consolekit and console-tracker into the conf by enabling the module all three are enabled as a bundle.
correct
Well, let take an example from scratch to see what happens step by step when you enable a service. I will take the boot-user@ oblive service as example enabled at tree session. At assume that service
was not installed previously on the system, so very first use. The version used is 0.0.1.
On the example the following term means:
@ oblive -> boot-user@ oblive
service/ -> /usr/lib/66/service/
module/ -> /usr/lib/66/module/
conf/ -> /etc/66/conf/boot-user@ oblive
var/ -> /var/lib/66/system/session/
upstream configuration file -> conf/version/.boot-user@ oblive
user configuration file -> conf/version/boot-user@ oblive
When you install the boot-user@ -66serv service by pacman, pacman install the frontend service file at service/boot-user@ and the module part at module/boot-user@ .
When i do
66-enable @ oblive
it:
- Reads the service/@ oblive frontend file and parse it
- it make a copy of module/boot-user@ to service/@ oblive
- it apply the necessary changes on the service/@ oblive directories and files according to the [regex] section of the service/boot-user@ frontend file.
- it launch the service/@ oblive/configure/configure script which apply what you asked at the [environnment] section of the service/boot-user@ file. This is at this step that the service know if you want to apply the DISPLAY_MANAGER, CONSOLE_TRACKER, XDG_RUNTIME, DESKTOP_CMDLINE. If the DM is asked, it add the corresponding service to the list of 66-enable to enable.
- for each service found in the list to enable, it read the corresponding frontend file and parse it. This step is done recursively. So, if you have asked for the DISPLAY_MANAGER=sddm, it search on your system the sddm frontend file, read it and parse it and create the necessary directory for the service at var/. If the sddm frontend have a @ depends fields, it do the same (read, parse and create the necessary at var/).
- finally it create the necessary directory and files at var/ AND create the upstream configuration file. At this state the user configuration file doesn't exist. So, at first enable, the upstream configuration file is created, no need to use the -F.
By default the service should start correctly. But the default provided do not satisfy me, i want to change the behavior of the service.
When i do
66-env @ oblive
- it search if the user configuration file exist. If not, it create it. if exist, it do nothing.
- it search for EDITOR to use on the environment variable of your SHELL
- it launch the EDITOR and edit the user configuration file
As you can see the upstream configuration file is
not touched and you should never touch this file because your changes will be lost at the next call of the 66-enable. Also, the upstream configuration file contain a warning message about this fact.
So, now i editing the user configuration file and i want to apply it.
when i do
66-enable -F @ oblive
it do all step describe before. That means that the service/@ oblive is erased and created again from the module/boot-user@ directory, pass through the configure script and overwritte the upstream configuration file. It do a one more step. As you ask for overwriting a service already enabled, it check the difference between the previous enabled service and the current one. That means that it will enable/disable service according to the difference between the previous enabled service and the current one.
So, as you can see (again), the upstream configuration file is written again whatever if the file existed before or not.
If you don't apply the -F options, the service/@ oblive is kept as it and it do not pass through the configure script (remember, it's this one which is responsible to enable or not the DM according to the configuration file). So, in that case the change that you made at your user configuration file is not applied.
Now what happens at a service upgrade. pacman install the frontend service file at service/boot-user@ and the module part at module/boot-user@ (so the previous one is completely erased).
The service will continue to works as it till you don't enable it again.
Now, i enable it again to apply the change.
When, i do
# 66-enable -F @ oblive
it do all the step. So, the new upstream configuration file is created at conf/version/0.0.2/.boot-user@ oblive then the user configuration file from 0.0.1 is automatically copied to version/0.0.2. At the end of the process, you have the upstream configuration AND the user configuration file coming from your previous version. The -I option avoid that. If you use it, the user configuration file from the previous version is not copied and you only have the upstream configuration file.
To finish, whatever the case you always have an upstream configuration file which contain the necessary to start the service correctly whatever the change made on upstream. If the user configuration file exist, you never loose your changes because the file is never touched by 66-enable.
Hope this explanation help to understand how the things work.