Systemd programming part 2: activation and language issues

This.

When invoking systemctl enable/disable, systemctl/systemd only has to look at [install], other sections can be ignored.

Similarly, when systemd is constructing its dependency tree, it only has to look at the [unit] section, [install] and [service], etc, sections can be ignored. And when it's actually invoking the unit, only the [service], [socket], etc, sections as appropriate, must be considered, [install] and [unit] can be ignored.

While I've no idea whether systemd is actually coded this way, from back in my MS days I know their ini-file APIs were setup to work exactly that way. The API allowed you to open a particular ini file, then specify section and key (IIRC they used the term "value", which always confused me) to return or set, with its value (which they termed "data", as "value" referred to the key) then returned or set. Other sections might as well not have existed at all, and in fact, could belong to entirely different applications (as was the case in MS Windows 2.x I believe, when all sorts of apps had sections in win.ini, before 3.x introduced dedicated application ini files).

So access is (at least conceptually) by section and then key, and if key names don't overlap between sections, it's only to avoid human confusion, not because they couldn't, as to the application, if they're in different sections they are (or should be) entirely different things, regardless of what they're named.

Duncan