From: matthew@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 
  
 -----BEGIN PGP SIGNATURE----- 
  
 iQIzBAABCgAdFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAmjefqAACgkQEvTSHI9q 
 Y8in4BAAp/jcl5NsvZO7aXMnoOEFCBn9LqRDJbyh+dAp4x8EiSaarj1u0TuXWz90 
 oICrFI50P2GkLLyD+5AvNO6YJCVAvZ+368qkpmf5/Ghhiln07Gm4OtYyxtV790/H 
 +HlOd71e68sjBHWdKYno4VBMrmLI3AJQ7Z/piu4NvYwf6wvf73e3IiyAPW9SAZjx 
 tM0hNipOQ5cxRNHaw+c82VqF6iMP9Cu+1uiq2eEJWvCuo1SzxAKk84lioASooEQh 
 ynloaKYSg+PCZCbnyQAaQIMTdxpdSueaqvrROh4Co2FHdX39ecV0ZFfXEeQKmXRY 
 IxVOexSlQmvuKceZ2c9jrwlkYQ3T+72DAznjnkTRtKxMylk6Vgi65GWGrxv7pdnb 
 ft8l5GdI+5sgYoag7fr4t7VZ9umpCWnT2RC58jjBTi6Ah4/ucVAHn5rsM+53vuEi 
 t6heFZh61Q2GtSZy33n9FycECvPJEipMri54mgxZQ5RS+lCxmRgRoJ3vr9uzd1XC 
 LGdIELAcw+/de8qFRaJ4beKb74fQvh6TVa+Tksgj9IzDqa0N84A6GZNa7+lNFvPz 
 ijX4Lafd1C57aKpyTeWKPUjG6ydNOebPbtfQoCikF0M7NbpfYBGVss1YMuF/j50F 
 BSOgO7VeZzo7QU5dZ7NE0zygExzf2lgl3aHOI35jonbEs+DPhsQ= 
 =xauO 
 -----END PGP SIGNATURE----- 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)