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/

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTumtb5BSD6EfafSCRHew2wJjpU2AUCaOFBOgAKCRBHew2wJjpU
2MK6AQD4QCOcyWX8O9F+YKZ/JPSAdRkbnEy3U7ikFD35ppToMAD/cqW6nehFg0cy
in41qwmNBEz7yqGcAKQ6xMiX9JOlqQY=
=Hms9
-----END PGP SIGNATURE-----