Bug#1115317: call for votes
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 signature.asc Description: PGP signature
Bug#1115317: call for votes
I vote, A > C > B > N The newer locking method is way better but we cannot strand programs that use it. I'd strongly suggest they do move to flock though. Such change needs a careful transistion plan as part of the whole point is for different programs to know if the device is in use. signature.asc Description: PGP signature
Bug#1115317: call for votes
Hi Matthew (2025.10.02_14:57:12_+0200) === 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: A > C > B > N The change in systemd seems to be in the right direction, but some steps still need to be taken to get the project there. There is a transition that needs to be coordinated. So I support changing systemd to support the old style lock files until this transition is complete. If we reach the point that policy has been updated, the transition is probably done. But I wouldn't want to put what's really a Release Team call onto the Policy Editors, so I prefer A to B. I'd rather it was our problem than the Plicy Editors, so I prefer C to B. I am comfortable in the non-specific project decision in A, so I rank it first. I hope somebody will step up to coordinate this transition and get it done soon. Stefano -- Stefano Rivera http://tumbleweed.org.za/ signature.asc Description: PGP signature
Bug#1115317: call for votes
Hi, * Matthew Vernon [2025-10-02 13:57]: === 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 A > C > B > N I think it is important that the TC expresses clear expectations, and I feel option B is too vague and implicitly asks the Policy editors to rule in our stead, which puts undue burden on them. I rate option A over option C because I'd rather see the usual Debian processes take over and not make the TC the defacto transition driver. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1115317: call for votes
> === BEGIN === > Ballot options: > > A) Issue items 0 + 1 > B) Issue items 0 + 2 > C) Issue items 0 + 3 > N) None of the above > > === END === Sorry for being late, I was called on a surprise business trip for all of last week until today. FTR, I agree with overriding the systemd maintainer(s) here. A = B = C > N Christoph signature.asc Description: PGP signature
Bug#1115317: call for votes
On Thu, Oct 02, 2025 at 02:31:15PM +0100, Matthew Vernon wrote: 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. The /var/lock change is a good change for us to target. We can't do it without coordinating a transition[1]. I look forward to this change to the distro, and think it's a good thing for the ecosystem to move to. I'm happy to see this change in general. Because I don't like the idea of TC being involved on an ongoing basis with implementation *and* transition, so i'd rather be clear on the acceptable end-state and let the project work it out - I vote: A > C > B > N [1]: The Release Team considers everything a transition where the upload of a package requires changes (rebuilds or actual patches) to reverse dependencies. (from https://wiki.debian.org/Teams/ReleaseTeam/Transitions) -- ⢀⣴⠾⠻⢶⣦⠀ Paul Tagliamonte ⣾⠁⢠⠒⠀⣿⡁ https://people.debian.org/~paultag | https://pault.ag/ ⢿⡄⠘⠷⠚⠋Debian, the universal operating system. ⠈⠳⣄⠀⠀ 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3 signature.asc Description: PGP signature
Bug#1115317: call for votes
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: A > C > B > N signature.asc Description: PGP signature
Bug#1115317: call for votes
Hi, The outcome is no longer in doubt, the winner is: A) Issue items 0 + 1 The Technical Committee resolves as follows: === 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. 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. === END === Regards, Matthew pgp3KWxw6demR.pgp Description: OpenPGP Digital Signature
Bug#1115317: call for votes
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 pgpIKSi7kmGXb.pgp Description: OpenPGP Digital Signature
Bug#1115317: call for votes
Hi, I call for a vote on the following ballot (I fixed the grammar of option 2, and renamed the none of the above option per constitution, but this is otherwise as the last draft). The vote runs for a week, or until the outcome is no longer in doubt. Regards, Matthew === 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 === pgph6aaatM9vG.pgp Description: OpenPGP Digital Signature
