update-alternatives
can indeed be used to manage symlinks under /bin
, or even anywhere else; that’s its purpose. It requires cooperating packages, or manual setup — the various alternatives need to be registered.
dpkg-reconfigure
isn’t specific at all, it only runs a package’s post-installation maintainer script. So its behaviour is entirely dependent on the specific package it’s used to configure. In bash
and dash
’s case, the maintainer scripts handle the /bin/sh
symlink, so yes, in this particular case dpkg-reconfigure
is used to manage a symlink.
The reason why bash
and dash
don’t use update-alternatives
to manage the /bin/sh
is simply that when the possibility was enabled, update-alternatives
wasn’t considered robust enough to be relied upon for such a sensitive file as /bin/sh
. If anything ever goes wrong and /bin/sh
ends up either removed, or pointing at a non-existent file, the system is rendered largely useless and hard to fix; it won’t even boot properly... So bash
and dash
take great care to ensure that /bin/sh
is always usable. This involves some careful processing in their pre-installation “script” (which is actually a binary, to avoid pre-dependency loops), a trick involving dpkg-divert
, and some last-ditch handling in their post-installation scripts. You’ll find details of the design of all this in bug #34717 (nineteen years ago).
To tell which binaries in a system are handled using alternatives, and which are handled using diversions (from maintainer scripts), you can use the corresponding tools, in particular dpkg-divert --list
which will list all diversions. For update-alternatives --list
you need to know the alternative group you’re interested in, but alternatives are easy to spot because they’re all symlinks to a file in /etc/alternatives
.