A package for an MTA (for example) will have to know how to start
itself up. You're left with the following options:
1. Rework the MTA to startup with your own method
2. Have the package maintainer somehow allow both such as...
3. Post to the AUR (or whatever) another version of the same
package that uses the alternate startup system.
That's why a declarative service config files help.
An alternative init system could just read the "systemd" ini files and
do whatever it thinks it can do better.
I'm confused as to how this solves the problem. Sounds like
you've just introduced parsing into the mix ---- another
unnecessary complication.
I don't understand why you think parsing is a hard thing. INI files have
been around for millennia (in internet years) and both parsers and
writers for them are well established in many languages.
Also, bash scripts are also parsed, for better or worse.
The benefit of declarative config files is that you can extract
information from them by *just* parsing and not by parsing AND running
them as is the case for random init scripts.
Also, even making a small error in a Turing complete bash script is much
more dangerous than in a declarative file, in which you'd just ignore
that line.
--
дамјан
