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.
A path-based interest is chosen following the same rationale as
pve-manager commit 27d1db3a ("triggers: add path-based trigger
interest").
Re-using pve-api-updates would be possible, but not quite fitting and
also would require a lintian override since the package is also
activating that trigger. If using a name-based trigger, then it should
rather be a dedicated one.
Signed-off-by: Fiona Ebner <[email protected]>
---
Maybe the approach with an explicit trigger name is better here?
debian/pve-firewall.triggers | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/pve-firewall.triggers b/debian/pve-firewall.triggers
index 59dd688..ea8e9e2 100644
--- a/debian/pve-firewall.triggers
+++ b/debian/pve-firewall.triggers
@@ -1 +1,2 @@
activate-noawait pve-api-updates
+interest-noawait /usr/share/perl5/PVE
--
2.47.3
