On Thu, Oct 02, 2025 at 01:57:12PM +0100, Matthew Vernon wrote: > === 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 === I vote C > B > A > N. Rationale We appear to have general consensus that flock-based locking is technically superior and that we'd like it to be used. What we don't quite agree yet is how to get there. The systemd approach has been to deprecate and break the earlier locking scheme. As with other committee members, I do not agree with that being a reasonable price to pay. We're taking issue with how the transition is being done, not about the direction of the transition. The implied question here is whose responsibility it is to perform the work required to get there. Answer A would practically require the systemd maintainers to send a ton of patches for software half of which we consider ready for a museum. I hope that we can find a solution where the load can be shared in a better way. If that migration were to happen, updating policy to match the status quo would usually be easy, so B offers more ways to fulfil the imposed requirement than A. I favor option C, because I expect it to put the least work on systemd maintainers. Even though this causes the matter to go through the committee again, it provides a pretty clear path that should leave few disputes and misunderstandings behind. I caution that putting up higher standards for a transition plan than we apply to other transitions would not be reasonable. For instance, requiring a detailed schedule far in the future would appear unwarranted to me. On the flip side, an estimate of which packages are affected is something we'd probably want here. Helmut
Attachment:
signature.asc
Description: PGP signature