Alberto, I think you might be too deep in sysvinit paradigms how we did (hack) things before.
I personally think that mapping the functionality 1:1 is a wrong approach because you will end up in some impossible scenario in the end anyway. I think the better way how to convert openvpn to systemd would be: to convert all AUTOSTART= VPNs to openvpn@ enabled instances and all other to disabled openvpn@ instances at upgrade time. I guess there might be a need to some more subtle tweaking, but I think you can autoconvert most of the old configuration this way. So I would suggest to write down all current use cases and write down a solution for sysvinit and systemd for each of the use cases. The mapping "problem" -> "solution" could be more helpful than "current solution" -> "new solution". I don't think it's needed to support "I drop new configuration" and it get's picked automatically, but if you think it's needed, I think you can prepare openvpn.script that would: a) make a note which openvpn@ instances are autoconfigured (probably by having openvpn-auto@.service) b) walk through all AUTOSTART configurations and instantiate openvpn-auto@.service for each new configuration (not already managed by openvpn@.service c) when configuration disappears remove the auto-enabled openvpn-auto@.service In that way you will have: openvpn@.service # manually managed openvpn-auto@.service # automanaged openvpn.service # service script to manage opevpn-auto@.service(s) How does that sounds? Cheers, -- Ondřej Surý <ond...@sury.org> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410350460.596384.165821573.37360...@webmail.messagingengine.com
