Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1264778

Bug#1115317: call for votes

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Hi,

* Matthew Vernon <matthew@debian.org> [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 │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Thorsten Alteholz <debian@alteholz.de> - 2025-09-15 16:50 +0200
  Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Bdale Garbee <bdale@gag.com> - 2025-09-15 19:10 +0200
  Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Matthew Vernon <matthew@debian.org> - 2025-09-24 11:10 +0200
    Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Marco d'Itri <md@Linux.IT> - 2025-09-25 19:30 +0200
      Bug#1115317: Draft Ballot Re: Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Matthew Vernon <matthew@debian.org> - 2025-09-29 19:10 +0200
        Bug#1115317: Draft Ballot Re: Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Matthew Vernon <matthew@debian.org> - 2025-09-30 00:10 +0200
  Bug#1115317: call for votes Matthew Vernon <matthew@debian.org> - 2025-10-02 15:30 +0200
    Bug#1115317: call for votes Matthew Vernon <matthew@debian.org> - 2025-10-02 15:40 +0200
      Bug#1115317: call for votes Paul Tagliamonte <paultag@debian.org> - 2025-10-03 15:30 +0200
    Bug#1115317: call for votes Stefano Rivera <stefanor@debian.org> - 2025-10-04 18:00 +0200
    Bug#1115317: call for votes Timo Röhling <roehling@debian.org> - 2025-10-05 13:20 +0200
    Bug#1115317: call for votes Matthew Garrett <mjg59@srcf.ucam.org> - 2025-10-06 19:10 +0200
    Bug#1115317: call for votes Helmut Grohne <helmut@subdivi.de> - 2025-10-06 23:50 +0200
    Bug#1115317: call for votes Christoph Berg <myon@debian.org> - 2025-10-07 14:50 +0200
  Bug#1115317: call for votes Craig <csmall@debian.org> - 2025-10-06 23:00 +0200
    Bug#1115317: call for votes Matthew Vernon <matthew@debian.org> - 2025-10-06 23:30 +0200
  Bug#1115317: Technical Committee resolution on /var/lock and systemd Matthew Vernon <matthew@debian.org> - 2025-10-07 11:10 +0200
    Bug#1110980: Bug#1115317: Technical Committee resolution on /var/lock and systemd Simon Josefsson <simon@josefsson.org> - 2025-10-07 14:00 +0200
      Bug#1110980: Bug#1115317: Technical Committee resolution on /var/lock and systemd Santiago Vila <sanvila@debian.org> - 2025-10-07 14:30 +0200
      Bug#1110980: Bug#1115317: Technical Committee resolution on /var/lock and systemd Helmut Grohne <helmut@subdivi.de> - 2025-10-07 19:30 +0200
        Bug#1115317: Technical Committee resolution on /var/lock and systemd Simon Josefsson <simon@josefsson.org> - 2025-10-07 19:30 +0200
      Bug#1110980: Bug#1115317: Technical Committee resolution on /var/lock and systemd Marco d'Itri <md@Linux.IT> - 2025-10-07 22:10 +0200

csiph-web