Bug#1115317: Technical Committee resolution on /var/lock and systemd
unarchive 1110980
reopen 1110980
severity 1110980 important
tags 1110980 - wontfix
block 1115317 by 1110980
quit
Hi,
In #1115317, the Technical Committee (TC) was asked about the future
of /var/lock, following a systemd upload which made this directory
only writable by root. Bug #1110980 was opened against systemd,
pointing out that FHS (and thus Debian Policy) has /var/lock as the
standard interface for system-wide locks of serial devices and
similar.
In the upstream discussion of the issue (
https://github.com/systemd/systemd/issues/38563 ) the systemd authors
declined to remain FHS-compliant, but rather noted that downstream
distributions might wish to arrange for systemd to create /var/lock
with appropriate permissions if they wish to. Nevertheless, #1110980
was closed "wontfix".
The TC is sympathetic to the argument that flock(2) is a superior
locking mechanism, and that an end-state where all existing software
that still uses locks in /var/lock is migrated to using flock(2)
instead would be desirable.
The Technical Committee notes that an important part of the role of
a Debian Developer is ensuring that software in Debian complies with
Debian Policy. That a particular upstream is not interested in FHS
compliance is not a sufficient reason for a Debian package to
disregard the FHS as it is incorporated into Debian Policy.
The TC therefore resolves that systemd shall provide /var/lock with
relaxed enough permissions that existing Debian software that uses
/var/lock for system-wide locks of serial devices (and similar
purposes) works again. The TC exercises its power under constitution
#6.1.4 to overrule the systemd maintainers in this regard.
This change to systemd must persist until a satisfactory migration
of impacted software has occurred and Policy updated accordingly.
Thanks,
Matthew, for the Technical Committee
Reply to: