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
