YunoHost postinstall hook execution order during application upgrades

Direct resolution

The YunoHost postinstall hook is executed by the yunohost hook framework after the Debian package postinst completes, but its ordering relative to the core’s internal service-reconciliation step is not declared in app.conf metadata. Consequently, the hook is not guaranteed to run after service-reconciliation on every supported Debian release.

An application package cannot presently declare a dependency on the completion of the core’s service-reload phase within app.conf. The manifest provides no standardized field for this ordering constraint, so packagers must rely on undocumented script sequencing or manual placement within the hook directory.

To detect ordering regressions when the underlying OS moves to a new major Debian version, packagers should:

1. Inspect the executed postinstall script in /usr/share/yunohost/hooks/ or the package postinst to verify whether it invokes systemctl reload or otherwise depends on core reconciliation.
2. Review YunoHost release notes and the GitHub changelog for any mention of postinstall hook ordering changes between versions.
3. On a test system, perform an application upgrade while monitoring service state transitions with systemctl status and journalctl -u service-name during and after hook execution.

If the target system runs a Debian release where the default init system is systemd, the init-system shift changes when daemons become available relative to script execution. Verification on the actual deployed release is recommended before assuming prior ordering holds.

To further refine this recommendation, could you share the target Debian release version? This detail determines whether the init-system shift from SysV to systemd applies and whether the above monitoring steps are sufficient.