Bug#1115317: Technical Committee resolution on /var/lock and systemd

[Helmut Grohne <helmut@subdivi.de>]

Hi Simon,

On Tue, Oct 07, 2025 at 01:54:10PM +0200, Simon Josefsson wrote:
> Has it been discussed that /var/lock could be provided by some other
> package than systemd?

Technically speaking, /var/lock is owned by base-files. It is a symbolic
link pointing to /run/lock. So let's pretend you really asked about
/run/lock instead.

> Is there a reason the /var/lock directory MUST be provided by systemd
> and no other package could provide it?

systemd used to install /usr/lib/tmpfiles.d/debian.conf with a line

    d /run/lock    1777 root root -   -

overriding the systemd upstream configuration
/usr/lib/tmpfiles.d/legacy.conf containing

    d /run/lock 0755 root root -

as the earlier lexicographical occurrence takes precedence. We could
have a file /usr/lib/tmpfiles.d/fhs_run_lock.conf adding this back and
it could also be installed by a different package, so yeah what you're
proposing could be a middle ground.

> Then all packages that need /var/lock in Debian can depend on this
> 'var-lock' package, which would also allow us to better track which
> packages still use this suboptimal interface for device locking.  Or
> just move the directory to 'base-files' or similar.

I relate to the idea of only installing a permissive /run/lock when
there is a package that actually benefits from it. Keep in mind though
that what is being objected here is not the change itself, but the way
it is being done. Once said package exists and policy is updated to
document the additional dependency needed for obtaining FHS semantics,
systemd can go back to its restrictive /run/lock permission.

We hope that a solution is being found and that the requested reversion
is of temporary nature without imposing what that solution is.

Also keep in mind that we cannot just move packages from /var/lock based
locking to flock() based locking one at a time. If two different
packages compete about a device and they use different locking schemes,
they'll both think they had exclusive access. Going for flock()
practically needs to be a flag-day transition where all packages are
updated at roughly the same time.

Helmut