[Exherbo-dev] systemd paludis uninstall phase

Wulf C. Krueger wk at mailstation.de
Mon Jan 17 17:32:09 GMT 2011

> 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.

>         # 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20110117/78c5ebc2/attachment.pgp>

More information about the Exherbo-dev mailing list