Bug#1115317: call for votes

Matthew Vernon <[email protected]> Thu, 02 Oct 2025 14:31:15 +0100

Newsgroups	gmane.linux.debian.devel.ctte
Message-ID	<87v7kxbfbw.wl-matthew__43857.6741422125$1759412005$gmane$org@debian.org>

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

signature.asc (application/pgp-signature, 833 B)