Similar to the services shipped by pve-manager, the firewall service
should also be reloaded when Perl packages like libpve-common-perl or
libpve-network-perl are updated. There are false positives too, like
libpve-storage-perl, and avoiding theses would require a new trigger
name specifically for firewall and activating that new trigger in all
its dependencies. But maybe that one is the better way? Happy to hear
opinions :)
A path-based interest is chosen following the same rationale as
pve-manager commit 27d1db3a ("triggers: add path-based trigger
interest").
Note that this is not prompted by an actual issue I encountered, but
I did notice it when the firewall was still running with some manually
added logging in Daemon.pm even after reinstalling pve-common. I was
surprised and I felt like it's worth discussing whether we want any
triggers for the firewall service.
pve-firewall:
Fiona Ebner (3):
d/postinst: handled triggers by reloading service
d/pve-firewall.triggers: add interest in PVE perl code updates
d/pve-firewall.triggers: drop superfluous pve-api-updates activation
debian/postinst | 4 ++++
debian/pve-firewall.triggers | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
Summary over all repositories:
2 files changed, 5 insertions(+), 1 deletions(-)
--
Generated by git-murpp 0.5.0
