home bbs files messages ]

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