From: helmut@subdivi.de   
      
   Hi Santiago,   
      
   On Wed, Feb 11, 2026 at 02:12:55AM +0100, Santiago Vila wrote:   
   > I agree that this is an inconsistency and that we should try to fix it,   
   > but I don't really know how much risky the solution will be.   
   >   
   > The attached patch seems to work for me, I tested it by doing this:   
   >   
   > dpkg -i base-files_14.0_amd64.deb   
   >   
   > and nothing bad seems to happen. After the new base-files is installed,   
   > both /var/lock and /var/run are symlinks, while they still belong to   
   > base-files, and the postinst does not do any dirty trick anymore.   
      
   The safety aspect is difficult to judge. Maybe Guillem knows more here.   
      
   Generally, I would assume that dpkg could legitimately remove /var/lock   
   (as it might think it was a directory) and later recreate it as a   
   directory (making it temporarily unavailable). That could plausibly   
   cause a small window where /var/lock could be unavailable. Maybe that's   
   not what dpkg does today, but I would not consider such semantics a bug   
   in dpkg given the apparent type change.   
      
   > I have not tested if debootstrap handles this ok or not.   
   > (can anybody help me to test that?)   
      
   Bootstrapping should just work as the location becomes unpacked by dpkg.   
      
   The other piece that might be affected is downgrades of base-files.   
      
   From my pov, the safe play would be adding protective diversions as we   
   did for /usr-move:   
      
    * In the new base-files.preinst, create a protective diversion on   
      scheduled upgrades crossing the relevant version boundary.   
    * In the new base-files.postinst, always remove the diversion (so it   
      does not stay around).   
    * In the new base-files.prerm, create a protective diversion when   
      "upgrading" to an old version crossing the relevant version boundary.   
      
   Note that the diverting package must be neither base-files nor   
   drbd-utils since we want the diversion to affect both of them.   
      
   Thus the diversion would be created before upgrading (or downgrading)   
   and removed when /var/lock is a symlink in the dpkg database. After a   
   downgrade, the diversion would remain permanently (until upgrading   
   again). Thus all dpkg operations would be diverted away from the symlink   
   until the on-disk state is reconciled with reality at which point dpkg   
   should be happy.   
      
   > And I also don't know if it's ok to do this change in base-files   
   > before we fix drbd-utils, or maybe we should fix drbd-utils first.   
      
   Since the ownership of the location remains with base-files, drbd-utils   
   should be fixed first. It does not need to depend on a fixed base-files,   
   but base-files should likely express conflicts with old drbd-utils   
   before it removes the protective diversion.   
      
   > If we make /var/lock to be a symlink which belongs to base-files and   
   > drbd-utils is fixed later so that it does not contain /var/lock   
   > anymore, what will happen with /var/lock?   
      
   Chances are "nothing bad", because from a drbd-utils point of view   
   /var/lock is a shared file (with base-files) and since there are other   
   references, it will not be touched. However given metadata tracking in   
   dpkg, I would not want to rely on this and rather block the base-files   
   fix on drbd-utils being fixed first.   
      
   Helmut   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)