Ok, admittedly I'm excited because it works. The High Points:
+ It works (ok, yeah, it took me long enough.) + Framework-neutral grammar for bringing services up and checking them, no case-switches needed + Uses symlinks (of course) to declare dependencies in a tidy ./needs directory + Can do chain dependencies, where A needs B, B needs C, C starts as a consequence of starting A + Chain dependencies are naive, having no concept of each other beyond what is in their ./needs directory, so you do NOT need to declare the kitchen sink when setting up ./needs + Is entirely optional, it is off by default, so you get the existing behavior until enabled + Simple activation, you enable it by writing a "1" to a file + Smart enough to notice missing definitions or /service entries, a script will fail until fixed The So-So Points: ~ Framework grammar makes the working assumption that it follows a tool-command-service format. This might be a problem for future frameworks that require tool-service-command or other grammars. ~ Some distro maintainers may have situations where they compile out something that will be defined in a ./needs, or may compile in something that is missing from ./needs; this mismatch will bring tears, but for now, I am assuming that things are "sane enough" that these inter-dependencies will remain intact. ~ I'm not happy with handling of ./env settings, it could have been cleaner ~ Oversight of dependencies is based on the assumption that the supervisor for the dependency will keep the service propped up and running. ~ Once enabled, you need to start or restart services. It doesn't affect running services. ~ Currently starting a scripts sends the commands up, then check. Maybe it should do check, then up, then check? That feels wrong - at what point does it turn into turtles all the way down? The Low Points: - Not true dependency management. It only tackles start-up, not shut-down, and won't monitor a chain of dependencies for failures or restarts. - Enormous code bloat. By the time I finished with the bulk of exception handling, I felt like I ran a marathon...twice. The resulting script is *multiple* times the size of the others. - The number of dependent commands needed in user-space to run the script has gone up....way up. Every additional user-space tool included is another "does your install have X" that ultimately limits things - especially embedded devices. Did I mention bloat earlier? - Way too many failure tests, which means...way too many failure paths. This makes testing much harder. - There's a bug (or two) lurking in there, my gut tells me so.... - Relative pathing is fine for a static install inside of /etc, but what happens when users try to spawn off their own user-controlled services? I smell a security hole in the making... The Plan: This will become a part of avahi-daemon and forked-daapd definitions, but disabled by default. From everyone else's perspectives, it will function like it always did, until enabled. With sv/.env/ENABLE_NEEDS set to 1, for example, a launch of forked-daapd will bring up avahi-daemon, and avahi-daemon will bring up dbus. Constructive criticism welcome. I ask that Laurent leaves his flamethrower at home - the urge to burn it with fire to purify the project may be strong. ;)
