https://forum.obarun.org/viewtopic.php?id=1326

The only reference to this mysterious service is the above forum article and use by magicalsenpai

So how did he learn how to use it and why to use it?

Now we don't all need to know what each service is or does but this one seems to now be a dependency for consolekit?

I don't even use all this, but for testing purposes I have a tree boot-user with all the stuff the wiki says in the dm dbus configuration https://wiki.obarun.org/doku.php?id=dbus_and_dm

This tree is not enabled, but it had no problem, trying to enable it threw errors, destroying it and recreating throws errors, one of them was console-tracker not being active. It appears to me that if the boot-user tree is not enabled things just don't work, and you can't make a tree start after another tree unless it is enabled.


I need to make sense out of all this stuff I don't use so I can update the wiki at least, but my system ended up in havoc trying to get this working. It seems as 66 0.6.1 is working only if you don't destroy and recreate previously made trees.

Since some of those issues are obarun specific and not 66 related 66 documentation is of no help.
Interesting, I just switched to using it without any problems. All it seems to do for me was switch consolekit service from my root tree onto my boot-user tree, and added a oneshot console-tracker service, so I had to disable it on my root tree.

After I uncommented the respective line found after running the command # 66-env -t boot-user boot-user@ myusername
Specifically what exactly did you enable with console-tracker@ and where?
Specifically, CONSOLE_TRACKER=consolekit on the env file, then when I run "# 66-enable -F -t boot-user boot-user@ myusername" it altered my boot-user tree adding two "leaves"; one consolekit longrun service&one console-tracker@ consolekit module. I was mistaken calling it oneshot service in my earlier post.
Name         : boot-user
Initialized  : yes
Enabled      : yes
Starts after : root
Current      : no
Allowed      : root
Symlinks     : svc->source db->source
Contents     : /
               ├─(up,Enabled,oneshot) setenv@ orb
               ├─(1081,Enabled,longrun) svscan@ orb-log
               ├─(1129,Enabled,longrun) svscan@ orb
               ├─(up,Enabled,module) scandir@ orb
               ├─(up,Enabled,oneshot) mount-run@ orb
               ├─(1083,Enabled,longrun) consolekit-log
               ├─(1089,Enabled,longrun) consolekit
               ├─(up,Enabled,module) console-tracker@ consolekit
               ├─(1082,Enabled,longrun) sddm-log
               ├─(1094,Enabled,longrun) sddm
               ├─(up,Enabled,module) display-manager@ sddm
               └─(up,Enabled,module) boot-user@ orb

# 66-inservice -p10 console-tracker@ consolekit
Name                  : console-tracker@ consolekit
Version               : 0.2.1
In tree               : boot-user
Status                : enabled, up
Type                  : module
Description           : Enable console tracker consolekit
Source                : /usr/lib/66/service/console-tracker@ consolekit
Live                  : /run/66/tree/0/boot-user/servicedirs/console-tracker@ consolekit
Dependencies          : consolekit-log consolekit
External dependencies : dbus:root
Optional dependencies : None
Start script          : None
Stop script           : None
Environment source    : None
Environment file      : None
Log name              : None
Log destination       : None
Log file              : None
I'm not sure exactly its function, so I'm not sure what I enabled tho. I suspect it is to make it easier to switch between console managers like mild consolekit, questionable elogind&tyrannical systemd. Pardon if what preceded this was redundant.
I believe you, but how did you guess that on console-tracker@ I the variable I stands for consolekit, and it can't be anything else.

Can "I" be anything else?
It is a module type of service that has no environment, and there is not much you can do with it, it may as well be renamed /usr/lib//66/service/ct and

66-enable -t fuckdm -S ct
My bet is yes, "I" can be whatever console manager that can be executed from a 66 front-end service-file. Never know if eric&team has been coding something similar to consolekit to work best with obarun. ;)
So :)
console-tracker@ is a service as type module. This service allow us to enable any console tracker consolekit, seatd, elogind,<whatever> that you want to use. So, for example to use consolekit do: 
# 66-enable console-tracker@ consolekit
Obviously the frontend service of the console tracker to use need to be present on your system.

"Ok eric, but what you don't simply use directly the consolekit service instead of passing through a module".

let's take a really stupid example. I want a tree with service A, B and C depending of a console tracker, in my case consolekit. So i need to define the field @ depends for A B and C with @ depends=(consolekit). So far so good, it works as expected. Now, i wake up, i push the power button on my machine, i update my system and boom consolekit doesn't work anymore.
So, i want to change my console tracker to seatd. In that case i need to rewrite the frontend file of A B and C and change my @ depends field. No really practical (i repeat this is a stupid example).
Well, now i pass through the service console-tracker@ , what's happen? I don't need to rewrite the frontend file of A B and C, whatever the console tracker used the @ depends file of A B and C do not need to be changed because @ depends=( console-tracker@ consolekit). As far as is a instantiated service, the template name of the service (in your case console-tracker@ ) will always be recognized by 66-enable. 66-enable will search about the console-tracker@ service name, whatever the complete name of the instantiated service and it will found it.
So, this is really flexible.

@ fungalnet
you are not forced to use any console-tracker at all, just be sure to comment the CONSOLE_TRACKER variable at the boot-user@ configuration file.

I did this on the boot-user@ service to be more friendly for "lamba" user. In one pass you can enable the necessary to start an X session will a console tracker and DM.

Now, let go further about this "feature". You want to be able to active the network at boot time(i promise this will happen as soon as you can believe) and this whatever the program that you want to use to connect to your network. How you can accomplish this? I mean some user want networmanager, some other prefer connmand and another one prefer to configure a static ip.
Answer: network@
All service at my boot time that it need to start after the network connection will depends on network@ and now i can use any program that i want:
network@ connmand
network@ networmanager
network@ my_oneshot_service_which_configure_my_static_ip

This is clear or not?
eric wrote@ fungalnet
you are not forced to use any console-tracker at all,
I wasn't planning to, it was enabling a tree that worked in the past to see if lxdm would still work and consolekit failed. When I looked at its log to see why it is failing it said console-tracker not running/existing, can't remember. So I looked into console-tracker to see what it is, and the only reference I found was this one user mentioning it in his intree output, as console-tracker@ consolekit

Not only did I not make it work, the whole system locked up, no tty switch was possible. And again, tty@ tty4 on tree root for example, does not work with 66-0.6.1 , so tty service is only possible in boot for now. They appear as running but can't switch to any of them.
% sudo 66-disable -t lxdm -S consolekit 
66-disable: fatal: consolekit is a part of: console-tracker@ consolekit module -- it's not allowed to disable it alone
% sudo 66-disable -t lxdm -S consolekit console-tracker@ consolekit
66-disable: fatal: unable to remove service: console-tracker@ consolekit
Of course, how would you be able to since none existed.
So the solution, delete the tree:
Why would I want to do this, because boot-user will not work without enabling consolekit, and IF consolekit is enabled somewhere, as in an inactive tree, boot-user will not work:
% sudo 66-enable -v4 -F -z -t boot-user boot-user@ oba

66-enable(src/lib66/parser_utils.c: get_svtype_from_file(): 1319): tracing: read service file of: /usr/lib/66/service/consolekit
66-enable(src/lib66/parser_utils.c: get_svtype_from_file(): 1319): tracing: read service file of: /usr/lib/66/service/dbus
66-enable(src/lib66/parser_enabled.c: parse_add_service(): 370): tracing: add service: /usr/lib/66/service/console-tracker@ consolekit
66-enable(src/lib66/parser_utils.c: get_svtype_from_file(): 1319): tracing: read service file of: /usr/lib/66/service/console-tracker@
66-enable(src/lib66/ss_resolve.c: ss_resolve_src_path(): 265): warning: unable to find service: display-manager@ lxdm
66-enable(src/lib66/parser_module.c: parse_module(): 307): warning: unable to resolve source path of: display-manager@ lxdm
66-enable(src/lib66/ssexec_enable.c: start_parser(): 84): fatal: unable to parse service file: /usr/lib/66/service/boot-user@ oba: or its dependencies
Now, EVERY TIME, one unsuccessfully tries to enable boot-user 66 moves .xsession and xinitrc from "user"'s directory to *.bak
which means that if you try it twice your original files were rewritten. To me that is a major foul, without a warning deleting user's work.

So how does it really work? Only one way, delete EVERYTHING and start from scratch, and do it exactly in one particular sequence and order, one way, and there are no alternatives in configuring anything. It works one way.

So "modules" meant this thing has turned into a BRICK that either fits or doesn't work at all.
Like a systemd solution.

But even in this case there has to be a specific routine written in the wiki about how is this single ONE way expected to work.
And since I can not figure it out, there better be someone that knows how this monoblock is working these days. 66-enable -c and -C are deprecated, .... this is good to know.

Tired, tired, very tired of all those undocumented changes and even more so when I have to reconfigure and edit things I have done replaced unexpectedly by 66 only to end up with a problematic system.

I mention up on top what is the relation with consolekit and consoletracker as dependencies and there was no feedback. Obviously they are now so interdependent that you can not even disable consolekit if you had it previously from a tree unless you delete the tree. You can't enable it, or do it twice without it. So what gives? There is no flexibility in fixing this system anymore, delete all and start from 0.
@ fungalnet
keep cool my friend :). i know that's can be frustrating :)
first about the changes: https://web.obarun.org/software/66/v0.6.1.1/upgrade.html.
But i know that my communication is not sufficient about the changes. I try to do what i can and i try to find the time (really), but i'm overbooked.

so now look (i have an regular user called test on my system) 
66-tree -cn test
66-tree: info: Created successfully tree: test
66-tree: info: Set successfully: test as default

root@ S6 obarun # 66-enable boot-user@ test
66-enable: info: Enabled successfully: svscan@ test
66-enable: info: Enabled successfully: scandir@ test
66-enable: info: Enabled successfully: boot-user@ test

root@ S6 obarun # 66-env -V boot-user@ test
/etc/66/conf/boot-user@ test/0.4.2 current

root@ S6 obarun # 66-intree -g test          
Name         : test
Initialized  : no
Enabled      : no
Starts after : None
Current      : yes
Allowed      : root
Symlinks     : svc->source db->backup
Contents     : /
               ├─(unitialized,Enabled,oneshot) setenv@ test
               ├─(0,Enabled,longrun) svscan@ test-log
               ├─(0,Enabled,longrun) svscan@ test
               ├─(unitialized,Enabled,module) scandir@ test
               ├─(unitialized,Enabled,oneshot) mount-run@ test
               └─(unitialized,Enabled,module) boot-user@ test
now i editing the boot-user@ test and i uncomment DISPLAY_MANAGER and i enable again 
root@ S6 obarun # 66-enable -F boot-user@ test
66-enable: info: launch script configure of module: scandir@ test
scandir@ test: info: set live directory to: /run/66/
scandir@ test: info: enable service: setenv@ test
scandir@ test: info: enable logger options
scandir@ test: info: enable notification
scandir@ test: info: set verbosity level to: 3
scandir@ test: info: successfully configured
66-enable: info: launch script configure of module: boot-user@ test
boot-user@ test: info: enable service: display-manager@ sddm
boot-user@ test: info: set environment at .xsession file to: /home/test/.66/conf/svscan@ test
boot-user@ test: warning: move existing /home/test/.xsession file to /home/test/.xsession.bak
boot-user@ test: info: create /home/test/.xsession
boot-user@ test: info: enable service: mount-run@ test
boot-user@ test: info: set environment at .xinitrc file to: /home/test/.66/conf/svscan@ test
boot-user@ test: info: set commandline at .xinitrc file to: jwm
boot-user@ test: warning: move existing /home/test/.xinitrc file to /home/test/.xinitrc.bak
boot-user@ test: info: create /home/test/.xinitrc
boot-user@ test: info: successfully configured
66-enable: info: Disabled successfully: boot-user@ test
66-enable: info: Disabled successfully: setenv@ test
66-enable: info: Disabled successfully: svscan@ test
66-enable: info: Disabled successfully: svscan@ test-log
66-enable: info: Disabled successfully: scandir@ test
66-enable: info: Disabled successfully: mount-run@ test
66-enable: info: Enabled successfully: setenv@ test
66-enable: info: Enabled successfully: svscan@ test
66-enable: info: Enabled successfully: scandir@ test
66-enable: info: Enabled successfully: sddm
66-enable: info: Enabled successfully: display-manager@ sddm
66-enable: info: Enabled successfully: mount-run@ test
66-enable: info: Enabled successfully: boot-user@ test
root@ S6 obarun # 66-intree -g test          
Name         : test
Initialized  : no
Enabled      : no
Starts after : None
Current      : yes
Allowed      : root
Symlinks     : svc->source db->backup
Contents     : /
               ├─(0,Enabled,longrun) sddm-log
               ├─(0,Enabled,longrun) sddm
               ├─(unitialized,Enabled,module) display-manager@ sddm
               ├─(unitialized,Enabled,oneshot) setenv@ test
               ├─(0,Enabled,longrun) svscan@ test-log
               ├─(0,Enabled,longrun) svscan@ test
               ├─(unitialized,Enabled,module) scandir@ test
               ├─(unitialized,Enabled,oneshot) mount-run@ test
               └─(unitialized,Enabled,module) boot-user@ test
i edit again the boot-user@ test and i comment DISPLAY_MANAGER then i enable again 
root@ S6 obarun # 66-enable -F boot-user@ test
66-enable: info: launch script configure of module: scandir@ test
scandir@ test: info: set live directory to: /run/66/
scandir@ test: info: enable service: setenv@ test
scandir@ test: info: enable logger options
scandir@ test: info: enable notification
scandir@ test: info: set verbosity level to: 3
scandir@ test: info: successfully configured
66-enable: info: launch script configure of module: boot-user@ test
boot-user@ test: info: enable service: mount-run@ test
boot-user@ test: info: set environment at .xinitrc file to: /home/test/.66/conf/svscan@ test
boot-user@ test: info: set commandline at .xinitrc file to: jwm
boot-user@ test: warning: move existing /home/test/.xinitrc file to /home/test/.xinitrc.bak
boot-user@ test: info: create /home/test/.xinitrc
boot-user@ test: info: successfully configured
66-enable: info: Disabled successfully: boot-user@ test
66-enable: info: Disabled successfully: setenv@ test
66-enable: info: Disabled successfully: svscan@ test
66-enable: info: Disabled successfully: svscan@ test-log
66-enable: info: Disabled successfully: scandir@ test
66-enable: info: Disabled successfully: display-manager@ sddm
66-enable: info: Disabled successfully: sddm
66-enable: info: Disabled successfully: sddm-log
66-enable: info: Disabled successfully: mount-run@ test
66-enable: info: Enabled successfully: setenv@ test
66-enable: info: Enabled successfully: svscan@ test
66-enable: info: Enabled successfully: scandir@ test
66-enable: info: Enabled successfully: mount-run@ test
66-enable: info: Enabled successfully: boot-user@ test
root@ S6 obarun # 66-intree -g test          
Name         : test
Initialized  : no
Enabled      : no
Starts after : None
Current      : yes
Allowed      : root
Symlinks     : svc->source db->backup
Contents     : /
               ├─(unitialized,Enabled,oneshot) setenv@ test
               ├─(0,Enabled,longrun) svscan@ test-log
               ├─(0,Enabled,longrun) svscan@ test
               ├─(unitialized,Enabled,module) scandir@ test
               ├─(unitialized,Enabled,oneshot) mount-run@ test
               └─(unitialized,Enabled,module) boot-user@ test
As you can see the sddm service disappear. This is exactly the same behavior with CONSOLE_TRACKER.
You cannot disable a service directly if the service is a part of the module but you can edit its configuration file, comment the "service" and enable again the whole module.

As being said, you totally right, erasing the work of the user at .xinitrc and .xsession is unacceptable. I will fix that. Thanks my friend to point me out this.
As i said previously (on some thread, don't remember where), the implement of the user scandir is not well-made and for the moment my personnal test to change it for a good design do not satisfy me. So, i continue to search for the good way (mobinmob from Void, help me a lot about that).
But as the output shows, no matter what I do, 66-enable boo-user@ oba fails, so 66-env will not work with something that is not enabled. Editing manually the long-names .conf file, moving it, removing it, removing the entire /etc/66/conf/boo-user@ oba branch ... makes no difference, the 66-enable fails the same way.
With the -C option, or was it -c, you can have it overwrite and recreate a new default configuration, but now it doesn't.
After moving the ../conf/boot-user@ ... and trying 66-enable again the directory was not recreated.
so, you have something wrong somewhere.
First do you have any /etc/66/service/boot-user@ service?
Do you have any /etc/66/module/boot-user@ directory?

"The new default" is now ALWAYS created by default, you don't need to worries about that. The /etc/66/conf/boot-user@ <whatever>/version/.boot-user@ <whatever> is ALWAYS erased when you do 66-enable -F. Now, when you do 66-env boot-user@ <whatever>, 66-env will copy the the /etc/66/conf/boot-user@ <whatever>/version/.boot-user@ <whatever> file to /etc/66/conf/boot-user@ <whatever> (no dot prefix the file) if the file doesn't exist yet. If the file already, the copy is not made. Now when you do 66-enable -F it NEVER touch the/etc/66/conf/boot-user@ <whatever>.

So:
the .boot-user@ <whatever> is the upstream and ALWAYS overwritten.
the boot-user@ <whatever> is the user file and NEVER touched.

if you do 66-inservice -n envfile boot-user@ <whatever> you will see the name of two different file and the contents of each file like this(note the field environment variables from: which show you the origin of the file that you see): 
% sudo 66-inservice -o envfile boot-user@ obarun
Environment file      : 
                        environment variables from: /etc/66/conf/boot-user@ obarun/0.4.2/.boot-user@ obarun
                        # # [STARTWARN]
                        
                        # # DO NOT MODIFY THIS FILE, IT OVERWRITTEN AT UPGRADE TIME.
                        # # Uses '66-env boot-user@ obarun' command instead.
                        
                        # # Or make a copy of this file at /etc/66/conf/boot-user@ obarun/0.4.2/boot-user@ obarun and modify it.
                        # # [ENDWARN]
                        # # Uncomment it to use a display manager.
                        # # Can be any display manager as long as the
                        # # corresponding frontend file exist on your system
                        # # e.g sddm,lightdm,...
                        # # It also prepare the .xsession file.
                        # DISPLAY_MANAGER=sddm
                        # # Uncomment it to use a console tracker.
                        # # Can be any console tracker as long as the
                        # # corresponding frontend file exist on your system
                        # # e.g consolekit,elogind,...
                        # CONSOLE_TRACKER=consolekit
                        # # Create and mount the XDG_RUNTIME directory
                        # # at /run/user/obarun [yes|no]
                        XDG_RUNTIME=!yes
                        # # Command to use in your .xinitrc
                        # # to launch your desktop e.g.: openbox-session.
                        # # If commented the .xinitrc file is not configured.
                        DESKTOP_CMDLINE=!jwm

                        
                        environment variables from: /etc/66/conf/boot-user@ obarun/0.4.2/boot-user@ obarun
                        # # Uncomment it to use a display manager.
                        # # Can be any display manager as long as the
                        # # corresponding frontend file exist on your system
                        # # e.g sddm,lightdm,...
                        # # It also prepare the .xsession file.
                        # DISPLAY_MANAGER=sddm
                        # # Uncomment it to use a console tracker.
                        # # Can be any console tracker as long as the
                        # # corresponding frontend file exist on your system
                        # # e.g consolekit,elogind,...
                        CONSOLE_TRACKER=consolekit
                        # # Create and mount the XDG_RUNTIME directory
                        # # at /run/user/obarun [yes|no]
                        XDG_RUNTIME=!yes
                        # # Command to use in your .xinitrc
                        # # to launch your desktop e.g.: openbox-session.
                        # # If commented the .xinitrc file is not configured.
                        DESKTOP_CMDLINE=!jwm
So, for a same key=value found at both file the one used is the one found at boot-user@ <whatever> (so the user file)
eric wroteso, you have something wrong somewhere.
First do you have any /etc/66/service/boot-user@ service?
Do you have any /etc/66/module/boot-user@ directory?
No, and No. They did exist and since the conf file did have that lxdm defined in it I erased/moved away to /tmp and now it is clear.
eric wrote 66-env will copy the the
/etc/66/conf/boot-user@ <whatever>/version/.boot-user@ <whatever> file to
/etc/66/conf/boot-user@ <whatever> (no dot prefix the file) if the file doesn't exist yet. If the file already, the copy is not made. Now when you do 66-enable -F it NEVER touch the/etc/66/conf/boot-user@ <whatever>.
Ok, they didn't exist, but with the -F option they were created, so -F has taken up some functionality of the -C option that was reprecated? The wiki needs touch-up. I didn't use -F thinking I should use it after enabling and using 66-env In the past versions if you enabled a module that didn't exist the conf was populated by default, now it needs the -F to be populated with defaults, right?
eric wrote So:
the .boot-user@ <whatever> is the upstream and ALWAYS overwritten.
the boot-user@ <whatever> is the user file and NEVER touched.
Any chance I copied the previously existing into .boot-user@ ... or one of the interim 0.6.0 versions did and created havoc?
Maybe the reason I am trying to enable tty@ tty4 in root tree fails in practice but shows on 66-intree as active is the same case.
Because I just tried the same thing on live and tty@ tty** works.
eric wrote So, for a same key=value found at both file the one used is the one found at boot-user@ <whatever> (so the user file)
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. But manual editing didn't help either. I guess I should have edited the .boot-user@ conf file manually.

Oooouuuffff....!!!!! I must have seen that .boot-user@ file and thought I had saved it in the past as a backup, ....??
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.
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.

Powered by Obarun