Bug#1115317: call for votes

Matthew Vernon <[email protected]> Thu, 02 Oct 2025 13:57:12 +0100

Newsgroups	gmane.linux.debian.devel.ctte
Message-ID	<87wm5dbgwn.wl-matthew__46512.2511539207$1759411528$gmane$org@debian.org>

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 ===

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