On Fri, 20 Feb 2026 at 13:53:41 +0100, Santiago Vila wrote:
I was actually thinking about actively encouraging everybody to do the
switch by dropping /var/run in unstable to see what breaks
Please don't. I expect that the damage done in terms of programs not
starting or not working correctly would be completely disproportionate
to the cost of one symlink:
https://codesearch.debian.net/search?q=%2Fvar%2Frun&literal=1 currently
has 21291 results.
With upstream hat on, /var/run is mandated by the FHS, the interoperable
distro-independent location of the D-Bus system bus socket is
unix:path=/var/run/dbus/system_bus_socket, and the wording in the D-Bus
specification is carefully-chosen to allow (or even encourage) using
/run/dbus/system_bus_socket on systems like Debian where we know that
the two paths are equivalent. Making the two paths non-equivalent would
be a backward step, and I would prefer not to have to tell upstream
projects "sorry, yes, that's a weird Debianism and you'll have to work
around it" more than is strictly necessary.
Removing the symlink from base-files would also not have any effect on
systems that have systemd installed (because
/usr/lib/tmpfiles.d/var.conf creates it if necessary), so removing it
from base-files would be creating divergence between chroot/container
environments (schroot, podman, docker) and full-system environments with
systemd as init (lxc, systemd-nspawn, virtual machines, real hardware).
Similarly, it would not at all surprise me if there are chroot/container
managers that create /var/run -> ../run, if not already present, as part
of chroot/container startup, the same way we expect chroot/container
managers to be responsible for populating /dev, /proc and /sys. That
would partially mask the effect of dropping it from base-files.
smcv
