Forums before death by AOL, social media and spammers... "We can't have nice things"
|    linux.debian.bugs.dist    |    Ohh some weird Debian bug report thing    |    28,835 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 28,305 of 28,835    |
|    Simon McVittie to Santiago Vila    |
|    Bug#1039979: /var/run and /var/lock shou    |
|    20 Feb 26 14:20:01    |
      XPost: linux.debian.policy       From: smcv@debian.org              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              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca