I was testing the other day the instructions on dbus and dm wiki to implement on a user who denies any admin duties and things worked.
Then I thought I reverted the procedure as it is of no interest to me and discover that the process creates a permanent /usr/lib/66/service with my username in it. Should this be in /usr/lib/66 and not on /etc/66?
I follow testing, as I am a self designated tester :), and can't remember how I ended up with this weird package:

% sudo 66-mods.sh boot-user-@ oblive
66-mods.sh: fatal: module boot-user-@ doesn't exist
% sudo pacman -S boot-user-@ -66mod
resolving dependencies...
looking for conflicting packages...
:: boot-user-@ -66mod and boot-user@ -66mod are in conflict. Remove boot-user@ -66mod? [y/N] y
Package (2) Old Version New Version Net Change
boot-user@ -66mod 0.2.0-1 -0.06 MiB
observice/boot-user-@ -66mod 0.1.0-1 0.06 MiB
Total Installed Size: 0.06 MiB
Net Upgrade Size: 0.00 MiB
(1/1) installing boot-user-@ -66mod [------------------------------------] 100%
% sudo 66-mods.sh boot-user-@ oblive
66-mods.sh: fatal: /usr/lib/66/service/boot-user-oblive already exists



Anything on the wiki that contains user-@ should be changed to user@ and session-@ to session@ which means that any instruction in the forum written with this syntax should also be replaced.
What puzzles me is if I did this before 0.2.0-1 how did 0.2.0-1 replace the "different pkg" 0.1.0-1
Till I noticed the - difference I thought my pacman was broken.
I didn't given any instructions for the moment about the testing part.
Should this be in /usr/lib/66 and not on /etc/66?
Good point, maybe it's better to install the result of the 66-mods command at /etc/66/. Need to think about it.

So , yeah the modules was changed to follow the change at 66 instantiated service. Instantiated services are files where instantiated modules are directory. So to be consistent the name of Modules reflect now the instantiated service syntax.
I was clear at the start, modules are clearly on development. I mean the concept is not define entirely and the manner to deal with. That's why 66-mods.sh is a script instead of a C code and only present on Obarun (this is not shared with 66 even 66-tools).
So, you need to replace boot-user-@ -66mod by boot-user@ -66mod. User that already use the previous do not need to change nothing. It will works as it worked. But if you want to enable it again, you need first to disable the previous version and enable the new one.
The -f/F option will not works cause of the name change.

Also, the same rule need to be apply for all instantiated service. You don't need to do anything, just upgrade them, but if you want to enable them again, first disable and enable again. Do not pass by the -f/F option of 66-enable API.

Previously a command e.g 
# 66-enable dbus-session-@ oblive
give you a instantiated service named dbus-session-oblive in your tree
now when you do 
# 66-enable dbus-session@ oblive
will give you a service named dbus-session@ oblive :).
Why this change? Well let's take a another example 
# 66-enable dhclient@ eth0
gave you a service named eth0 which is not really usefull.
now the same command give you a service named dhclient@ eth0. It's clearer , isn't it? You know quickly the origin of the service. Also this change allow us to do some service declaration like this 
@ depends=( dhclient@ @I )
and the code by itself it less complicated (user don't care about this fact but me nope :) ).

So, yes the wiki need to be changed. For the forum part, let say you're are involving 66 :). User should always refer first to the official documentation. A prog evolve this is a normal thing.
What puzzles me is if I did this before 0.2.0-1 how did 0.2.0-1 replace the "different pkg" 0.1.0-1
i don't understand this o_O.

Powered by Obarun