[Debian-ha-maintainers] Bug#1082433: base-files: is /var/lock a directory or a symlink?

[Helmut Grohne]

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