=== suihkulo1ki is now known as suihkulokki [15:17] Keybuk: had a question about dependency behavior [15:18] sure [15:18] Keybuk: ok, so we want to start all possible services for a given set of states. [15:18] if service X depends on session, we start one per session [15:19] this is good [15:19] the easy way to do this is to scan the list of active states for each dependency of a state, and then take each combination of the results and make sure there's a service running for it [15:20] now, suppose we have a Session state, and a service G which depends solely on the Session state and auto-starts [15:20] so if we have user A and B logged in, they each have a service G [15:21] now, what if we start up a service C that depends on the Session state and on service G? [15:21] We get 4 copies of service C [15:21] One for your session/your service G, one for your neighbor's session and service G [15:21] one for your session and your neighbor's service G, and one for your service G and your neigbor's session' [15:22] Keybuk: I can fix this behavior a couple ways. what's the right way to behave though? [15:41] ahh, greetings, sirs [15:42] Steve-O! [15:42] it is I. what is up? [15:43] we were discussing some depsolving behaviors [15:43] related to depsolving dependent services? [15:43] sadmac2: sounds like some intelligence required there [15:44] ssalevan: yes [15:44] since neighbour's service G and our session are theoretically not compatible [15:44] Keybuk: well, the dumb solution is to match the parameter out of G. so you say when session and G($session_id) [15:45] Keybuk: but why bug the user with that when the typical behavior is probably never right? [15:45] it should do the right thing [15:46] Keybuk: what I have now is this "rooting" check. Basically any set of dependencies of any state cannot depend on anything outside that set iff something inside the set will meet the same dep [15:46] that sounds like it would dtrt [15:46] yeah, that's what I thought