XPost: linux.debian.policy   
   From: rouca@debian.org   
   Copy: 1039979@bugs.debian.org   
      
   Le lundi 9 février 2026, 10:18:37 heure normale d’Europe centrale Bastien   
   Roucaries a écrit :   
   > Le dimanche 8 février 2026, 20:36:32 heure normale d’Europe centrale Russ   
   Allbery a écrit :   
   > > This bug is a request to change the Policy requirement that /var/run and   
   > > /var/lock be absolute symlinks (to /run and /run/lock, respectively), and   
   > > instead be created as relative symlinks to ../run and ../run/lock. Debian   
      
   Hi,   
      
   Here we could replace lock -> /run/lock by run/lock   
      
   In this case only one symlink should be handled   
      
   > > has attempted to make this change in initscripts and base-files before but   
   > > rolled it back because Policy requires symlinks that cross root file   
   > > system directories to be relative links.   
   > >    
   > > The argument in favor of this proposal is that it makes working with   
   > > chroots easier. Specifically, if one is viewing or manipulating the   
   > > content of a chroot from outside the chroot, listing /chroot/var/run will   
   > > actually show the system /run, and creating files or directories in   
   > > /chroot/var/run will change system /run and have no effect on the chroot.   
   > > I agree that this is surprising and have run into this before.   
   > >    
   > > Debian's current policy on this is intended to support relocation of file   
   > > systems using symlinks. Specifically, it was quite common back in the day   
   > > to discover that you failed to correctly anticipate file system needs when   
   > > partitioning the disk and now you have a running server that's about to   
   > > run out of space in /var. A common solution was to copy the contents of   
   > > /var to some other partition that had more free space (/home, say) and   
   > > then symlink /var to that partition. In this case, symlinks such as   
   > > /var/run must be absolute, not relative. If we used relative symlinks in   
   > > the above example, /var/run (actually /home/var/run), symlinked to ../run,   
   > > would resolve to /home/run, which doesn't exist, probably breaking the   
   > > system.   
   > >    
   > > The counterargument to the current policy is that doing this with symlinks   
   > > is fairly obsolete and may well break other things these days (such as   
   > > some scenarios where the O_BENEATH flag is used). The preferred modern   
   > > approach would be to use a bind mount, which is invisible to path   
   > > resolution logic and would therefore work correctly with relative symlinks   
   > > as long as you encountered those symlinks via the /var path and not the   
   > > /home/var path.   
   > >    
   > > After thinking this over for a while this morning, I think I personally   
   > > find the argument for a change persuasive, but I'm nervous about it   
   > > because it does break an (admittedly fairly old and arguably obsolete)   
   > > common sysadmin technique. Obviously, anything we change would only be for   
   > > new systems; we shouldn't change anything about existing systems that may   
   > > already be configured with symlinked file systems.   
   >    
   > I think we should update and ask a debconf question during upgrade if we   
   detect    
   > /var being a symlink, that is the only problematic case, and upgrade if not   
   the case during preinst   
   >    
   > Moreover it will allow sysadmin possibility to bail out and use bind mount   
   if we detect a symlink   
   >    
   > > Perhaps documentation   
   > > in the release notes would be sufficient to move forward with this change?   
   > >    
   > > In short, I think symlinking file systems is no longer best practice, may   
   > > or may not be fully supported already (and probably isn't tested), and   
   > > therefore doesn't feel like it outweighs the clarity benefits for chroots,   
   >    
   > And docker and so on   
   > > but I'd like to get more feedback from others before we push forward with   
   > > proposing a change.   
   > >    
   > > This feels like the sort of change that maybe we should discuss on   
   > > debian-devel if it feels like we have consensus here on the Policy list.   
   > >   
   > rouca   
   >    
   >    
   >    
      
      
   -----BEGIN PGP SIGNATURE-----   
      
   iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmmJpvYACgkQADoaLapB   
   CF+iCA/9GiyRjuMkBb+tEATYykdV0GI4O/cu8t5QVHpC2sK3PxVm+tikld+zawhf   
   t/8zvWvyjjU6lP1Mibf965ckGHW6HDK2cPuq/EL6x1NqvxM4qn9Nx4Djq7r+nudC   
   a1XgXBM8E7cpb1duE/qQgwtC9z7WSsiVojoIFwacHgF+p3DTbC4hMk2ogq+lfwRc   
   IhgOGJJ9LlMqwGrTrt9tFJ5JbDex10YlF5XPmSjWGZSIUdfHNy/jdx5sU4Ur558H   
   xnILuMoxOC6PURhDn0MFnRmVMN4Uy+JoUonL2plDYoZDyY36G1JWOoS3YPyzlDyW   
   SPG0HvHcenLiv5P52MxuuSsNluBndEx2ghbennK1K83HrhQ/2UhKAMw3sfBbRwdv   
   6vvJSTmhqcZfCADupRK1MKRjvH00t9ZDbhFWkm8yKwwGOUM1QrsBkDjKhqFoiWB3   
   FPxmd8E6ZHUML5f45oSP7QIODKODUbVsQT2C+zQ4wWaiDw/dRZ8tMKXTNctjnO6t   
   F966LsjDtuwra6AJ1ZEuvDUGE+QADi+BOVlv2uO1U4bD/6eEIjrWsZWuaG69YCDV   
   fY5dKvcL8QqDWsNt443KHz1RO/vhGpRzUdDYpME1vTRNuUFI1BqYm0+1nGsIXMGo   
   yb2iiU+G/mkYRu/HJo4USK4adFPajZh5HF81W1eG+H+KmZ8cxHU=   
   =DPCy   
   -----END PGP SIGNATURE-----   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)