Quoting Didier Kryn (kryn@???):

> Don't remember which package depends on some libkerberos5.
> Assuming it's openssh or some component of pam.

Package openssh-client.

 $ ldd $(which ssh)
        linux-gate.so.1 =>  (0xb76ec000)
        libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7672000)
        libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb751a000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7516000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7502000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb74d3000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb738c000)
        /lib/ld-linux.so.2 (0xb76ed000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb72da000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb72b7000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb72b4000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb72ad000)
        libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb72a9000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7290000)
 $

On a system that actually uses Kerberos, pam_krb5.so also gets involved,
and I don't remember how that actually works. (I've done some Kerberos
in setting up Hadoop on CentOS 6, but not much more than just getting it
going.)

> This raises a fundamental problem of distros. openssh and pam must be
> able to make use of as many authentication protocols as possible to
> cover the needs of all users. How can you reach this goal without
> linking them to the corresponding libraries?

It is indeed a thorny problem. One common answer is the Gentoo-style
one where you employ USE flags or equivalent, and recompile & rebuild
packages to trim build dependencies.

It's certainly possible to carry out a similar action on a deb-packaged
distro by locally rebuilding deb packages, tweaking the 'rules' file
before compiling to reduce build dependencies. Or, as you say, there
could be regular packages with several different flavours, some with
more dependencies, some with fewer.

> The case of libsystemd0 is different. In an OS proposing
> systemd, it is normal to have libsystemd0, but not in a system which
> excludes it completely. Here is the choice Devuan faces: if systemd
> is installable, then many packages must depend on libsystemd, if no
> package depends on it, then systemd is not installable.

I followed you all the way to the last sentence, which I'm pretty
certain is simply not correct.

E.g., on my dest Debian 8 'Jessie' VM system (if I were to remove the
current embargoing of system from /etc/apt/preferences), I could remove
all packages that depend on libsystemd0, but then systemd would most
certainly be nonetheless installable.