Hi, > === BEGIN === > > 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 Policy has been updated > to allow otherwise. > > 3) 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 > C) Issue items 0 + 3 > N) None of the above > > === END === On the basis that I'd rather we just consider a transition plan than have arguments about whether a particular proposal meets the terms of a TC resolution, I vote: C > A > B > N Regards, Matthew
Attachment:
pgpfeMcr79Kcj.pgp
Description: OpenPGP Digital Signature