[Exherbo-dev] systemd paludis uninstall phase
Vasiliy G Tolstov
v.tolstov at selfip.ru
Mon Jan 17 17:48:59 GMT 2011
On Mon, 2011-01-17 at 18:32 +0100, Wulf C. Krueger wrote:
> > why paludis systemd-service does not contain this?
> For clarity's sake: You're referring to any package that installs systemd
> > %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.
of course. enable all not good idea.
> > # 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?
this can be checked by eclectic
> > # 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
> Exherbo-dev mailing list
> Exherbo-dev at lists.exherbo.org
More information about the Exherbo-dev