Bug#1039979: /var/run and /var/lock should not be absolute symlinks

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