>In particular:
>
> override_dh_installsystemd:
>- dh_installsystemd --no-enable --no-start
>+ dh_installsystemd --no-enable --no-start --no-stop-on-upgrade
>
>Unfortunately dh_installsystemd is, in a word, a trainwreck. Most of
>the options have semantics that are unintuitive from their names, and
>many have inscrutable side effects. To sponsor this, I would need a
>separate bug that explains why you are making this change, what you
>expect the effect to be, and what testing will be done to confirm
>correct behavior across the various relevant scenarios (new install;
>upgrade with landscape client running; upgrade with landscape client
>not running).
As one of those (in part) responsible for this trainwreck, I feel I
should jump in with some extra words of caution here.
*If* the intent of this change is to ensure that the landscape-client
service does not restart at all on upgrade, then this change is correct
and *potentially* safe on jammy (22.04), though it should be tested for
reasons that will become obvious below (it should also, as Steve has
noted, be documented).
On focal (20.04), it is absolutely not safe and can lead to the daemon
stopping and never restarting. When --no-start is used, the default
restart behaviour in *some* versions of debhelper is changed from
--restart-after-upgrade (the current default) to
--no-restart-after-upgrade (the older default). In versions of debhelper
prior to 13.6 in jammy, --no-restart-after-upgrade placed the "stop"
action in the prerm of the *old* version of the package, and the "start"
action in the postinst of the *new* version. This means that if you
transition from the --no-restart-after-upgrade behaviour to
--no-stop-on-upgrade, the "stop" action still takes place (because the
old version of the package on the system still has this in its prerm)
but your shiny new version won't attempt to start or restart the package
in its postinst, leaving the service dead.
If you need clarification on any of the above, please feel free to reach
out to me on IRC/MM but I would urge careful testing of any such change,
most especially on releases prior to jammy where this bug is still
extant in debhelper.
>In particular: dh_installsyste md: on-upgrade
>
> override_
>- dh_installsystemd --no-enable --no-start
>+ dh_installsystemd --no-enable --no-start --no-stop-
>
>Unfortunately dh_installsystemd is, in a word, a trainwreck. Most of
>the options have semantics that are unintuitive from their names, and
>many have inscrutable side effects. To sponsor this, I would need a
>separate bug that explains why you are making this change, what you
>expect the effect to be, and what testing will be done to confirm
>correct behavior across the various relevant scenarios (new install;
>upgrade with landscape client running; upgrade with landscape client
>not running).
As one of those (in part) responsible for this trainwreck, I feel I
should jump in with some extra words of caution here.
*If* the intent of this change is to ensure that the landscape-client
service does not restart at all on upgrade, then this change is correct
and *potentially* safe on jammy (22.04), though it should be tested for
reasons that will become obvious below (it should also, as Steve has
noted, be documented).
On focal (20.04), it is absolutely not safe and can lead to the daemon after-upgrade (the current default) to after-upgrade (the older default). In versions of debhelper after-upgrade placed the "stop" after-upgrade behaviour to on-upgrade, the "stop" action still takes place (because the
stopping and never restarting. When --no-start is used, the default
restart behaviour in *some* versions of debhelper is changed from
--restart-
--no-restart-
prior to 13.6 in jammy, --no-restart-
action in the prerm of the *old* version of the package, and the "start"
action in the postinst of the *new* version. This means that if you
transition from the --no-restart-
--no-stop-
old version of the package on the system still has this in its prerm)
but your shiny new version won't attempt to start or restart the package
in its postinst, leaving the service dead.
If you need clarification on any of the above, please feel free to reach
out to me on IRC/MM but I would urge careful testing of any such change,
most especially on releases prior to jammy where this bug is still
extant in debhelper.