Bug#1115317: Draft Ballot Re: Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)
Hi,
At the last TC meeting we discussed this bug; I think our conclusion
then was that systemd needs to comply with policy and thus FHS regarding
/var/lock which still needs to be usable for serial device locks, and we
talked about a couple of options for how bounded our decision should be.
I was asked to draft a ballot.
Here's a draft - please LMK you're OK with it or propose amendments.
I think the "The TC is sympathetic to..." paragraph represents
consensus, but if you'd like it to be ballot-optional, LMK.
===8<===
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.
0) 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.
1) This change to systemd must persist until a satisfactory migration of
impacted software has occurred and Policy updated accordingly.
2) This change to systemd must persist until the TC allows otherwise,
which the TC expects to do once a suitable transition plan has been agreed.
Ballot options:
A) Issue items 0 + 1
B) Issue items 0 + 2
N) Further discussion
===8<===
Thanks,
Matthew
Reply to: