> why paludis systemd-service does not contain this? For clarity's sake: You're referring to any package that installs systemd services.
> %post > if [ $1 -eq 1 ]; then > # On install (not upgrade), enable (but don't start) the > # units by default > /bin/systemctl enable foobar.service foobar.socket >/dev/null 2>&1 It's not desirable to enable any systemd service just because you chose to install it. Furthermore, there my be conflicting service files which the user must choose from, e. g. sshd.service and sshd.socket conflict with each other for good reasons and your example would simply issue an error message. > # Alternatively, just call > # /bin/systemctl daemon-reload >/dev/null 2>&1 || : Theoretically, that could be done but what if systemd is not the currently active init system? > # On uninstall (not upgrade), disable and stop the units > /bin/systemctl disable foobar.service foobar.socket >/dev/null 2>&1 > || : /bin/systemctl stop foobar.service foobar.socket >/dev/null 2>&1 || : While disabling a service would be possible, the user can do that himself easily enough if he so desires. Same for stopping said service. And again: What if you're not even using systemd as your init system when you uninstall a package? > # Reload init system configuration, to make systemd honour changed > # or deleted unit files > /bin/systemctl daemon-reload >/dev/null 2>&1 || : See above. > # On upgrade (not uninstall), optionally, restart the daemon > /bin/systemctl try-restart foobar.service >/dev/null 2>&1 || : You've upgraded a package. One instance of said package is still running from pre-upgrade times. You want to restart it later because your users need the running instance. In short: While some of the ideas presented on that site have their merits, they're assuming a lot (e. g. that systemd is always used and the only init system (which I'd love to see but that'll take some time yet ;->)). Those assumptions may hold true for Fedora (which they were primarily written for) but not for Exherbo (or other distributions for that matter). Thus, we didn't (and won't) implement them. Best regards, Wulf
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
