Hello Colin,

I dealt with a very similar problem when introducing the HWE variant for
the virtualization package. The solution I took
can be transposed to the OpenSSH case as follows:

- openssh-gssapi:
   - Add a binary helper for the purge case; this helper will detect the
counterpart's presence on the system
     and exit early (the helper's behavior can be adjusted for other purge
cases later on)
- openssh-gssapi and openssh
   - Insert a execute_after_dh_installdeb rule in d/rules to insert at the
top of ALL postrm scripts :
     if [ -f ${hook} ]: then source ${hook}; fi

Hector

On Fri, 18 Sep 2026 13:10:47 +0100 Colin Watson <[email protected]> wrote:
> On Wed, Sep 16, 2026 at 09:21:38PM +0200, Gábor Gombás wrote:
> >If openssh-server is purged after openssh-server-gssapi is installed,
> >the postrm script unconditionally removes configuration which it thinks
> >still belongs to openssh-server, while in fact, openssh-server-gssapi
> >has become the owner of that configuration. The deleted files involve
> >the host keys, sshd_config, and systemd unit activation, rendering the
SSH
> >service unusable. openssh-client/openssh-client-gssapi has a similar
problem,
> >although it is less severe.
>
> Tricky.  I'm quite busy right now but will look as soon as I can.
>
> >IMHO the best way to solve this issue would be introducing
> >openssh-client-common and openssh-server-common packages, and moving all
> >the common configurationt to those packages.
>
> This won't be enough, because at least the default sshd_config is
> slightly different between the two flavours.  So we'll have to have some
> other strategy anyway, at which point it may not be worth introducing
> even more packages ...
>
> --
> Colin Watson (he/him)                              [[email protected]]
>
>

Reply via email to