YunoHost postinstall hook execution order during application upgrades

Context

YunoHost applications rely on a sequence of lifecycle hooks—install, upgrade, postinstall, and remove—to configure services on the underlying Debian system. The postinstall hook is documented as the finalization step that wires services, sets permissions, and reloads daemons after the main installation or upgrade logic completes.

Problem

When an application upgrade replaces configuration templates or changes service definitions, the relative ordering of the upgraded package's postinstall hook versus the core's service-reload logic is not explicitly versioned in the app.conf metadata. This creates a compatibility boundary: a packager cannot declare whether their postinstall must run before or after YunoHost's internal service reconciliation step.

Constraints

• Debian major-version upgrades may change init-system behavior (systemd vs. SysV), affecting when daemons are ready to accept reloads.
• The packaging framework provides no sandbox or transaction rollback; a mis-ordered postinstall can leave services in a failed state without automatic recovery.
• Manual service manipulations by administrators bypass the hook sequence entirely and are not tracked.

Questions

1. Is the postinstall hook guaranteed to execute after YunoHost's internal service-reconciliation step for every supported Debian release?
2. Can an application package declare a dependency on the completion of the core's service-reload phase within app.conf?
3. What verification procedure should packagers use to detect ordering regressions when the underlying OS moves to a new major version?