&gt; The WantedBy value in the system definition file isn&#x27;t an absolute (nor are the similar values Wants&#x2F;Requr[i]es&#x2F;RequiredBy&#x2F;etc).<p>Is this true of the identically-named keys in the Unit section?<p>&gt; If I don&#x27;t like how the distro or packager has set up the service file, I can override it. ... This is the real reason why systemd uses key=value stores for units; merging them is trivial while merging shell scripts is decidedly not.<p>You should look at how OpenRC handles service dependency specification. It&#x27;s at <i>least</i> as flexible as the system you describe in systemd. :)<p>&gt; Putting the overrides in a separate directory is a pretty nice decision...<p>Yep. At dependency graph generation time, OpenRC examines its master config file at &#x2F;etc&#x2F;rc.conf as well as config files in &#x2F;etc&#x2F;conf.d&#x2F; for -among other things- additions to the need, use, before, &amp;etc declarations in the depends section of a given service&#x27;s init script. To augment -say- the &quot;use&quot; list in the openvpn service, either add the line<p><pre><code>  rc_use=&quot;my_custom_service&quot;
</code></pre>
to &#x2F;etc&#x2F;conf.d&#x2F;openvpn , <i>or</i> add the line<p><pre><code>  openvpn_rc_use=&quot;my_custom_service&quot;
</code></pre>
to the OpenRC master config file at &#x2F;etc&#x2F;rc.conf . If I -say- wanted to override OpenVPN&#x27;s default dependency on the &quot;net&quot; virtual service, I would add<p><pre><code>  rc_need=&quot;!net&quot;
</code></pre>
to &#x2F;etc&#x2F;conf.d&#x2F;openvpn (or perform a similar transformation as before and store in &#x2F;etc&#x2F;rc.conf).<p>&gt; I can make that symlink manually, if I want, or I can call...<p>To add the openvpn service to the &quot;custom_init&quot; and &quot;default&quot; runlevels, I would simply do<p><pre><code>  rc-update add openvpn custom_init default
</code></pre>
If I omit the runlevel, the service is added to the current runlevel. I <i>could</i> screw around with symlinks if I cared to, but why would I? :)<p>The OpenRC configuration processing system is <i>substantially</i> more powerful than I describe, handles the processing of OpenRC-standard config files [0] automatically, and lets you shift the complexity of a configurable init script that <i>should</i> be in a config file into a config file.<p>Because my overrides and augmentations to the distro-supplied init scripts are in text files stored in standard places, I -too- can easily put them in version control and track their changes over time.<p>[0] Which -shockingly enough- look exactly like what any Linux programmer would expect a non-XML non-JSON text config file to look like. ;)