On 07/20/2011 08:10 PM, Toshio Kuratomi wrote: > On Tue, Jul 19, 2011 at 3:24 PM, Ville Skyttä <ville.skytta@xxxxxx> wrote: >> On 06/22/2011 07:24 PM, Toshio Kuratomi wrote: >> First, daemons are usually restarted on upgrade after the old package >> has been removed, so if this is desirable and the trigger approach is >> used, the try-restart should be done in %triggerpostun instead of >> %triggerun, no? >> > Is the important part that the old package has been removed or that > the new package has been installed? If %triggerun is happening > sufficiently late, then using it allows us to only have on trigger > script rather than two. If it does make a difference, then you're > right, we should move the try-restart portion to its own > %triggerpostun. In my opinion it's quite clear: if it's desirable to restart daemons in %postun instead of %post, it should be done on %triggerpostun instead of %triggerun in this scenario as well. The only thing where I think it matters is that if there's something in the old package that needs to be cleaned up before restarting the daemon on upgrades or else it will cause the new daemon to malfunction some way, the %*un ones should be used. For example files present in the old package but no longer present in the new one whose existence will cause the new daemon to not work as it should (note that at %post time files still present have already been overwritten by ones from the new package). But regarding restarting the daemon in the case at hand: because sysv->systemd migrations are strictly limited to distro upgrade scenarios, I wouldn't personally mind it if the migrated services wouldn't restart at package upgrade time at all. This especially considering that running systemd-sysv-convert --apply foo is left for the user -- also telling users that migrated services might not restart before a reboot wouldn't be at all bad IMO. Not having to restart them would simplify scriptlets (and as noted earlier, if done properly, old packages using "service" in their %postun for restarting would work basically "for free" without further complication). > Documenting how and what you've tested would also be good as testing > these is one of the pain points when working on this. For now I've only thought about it more than a bit, and tested with various modified versions of the vdradmin-am package. I'll do some more tests this week and document and publish the results. Hopefully I'll manage to get enough done because starting from next week I won't have much time at all for that for a couple of weeks. What I will _not_ be testing is setups using other init systems besides systemd. The current scriptlets in the Wiki don't attempt to take them into account either. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging