Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1265135
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Newsgroups | linux.debian.bugs.dist, linux.debian.devel |
| Subject | Bug#1110980: Bug#1115317: Technical Committee resolution on /var/lock and systemd |
| Date | 2025-10-07 19:30 +0200 |
| Message-ID | <LDjFD-3sRL-1@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <LDbRL-3nRT-9@gated-at.bofh.it> <LviGJ-fwlg-7@gated-at.bofh.it> <LDewh-3pm3-3@gated-at.bofh.it> <Ljflg-7emT-7@gated-at.bofh.it> <LDewh-3pm3-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 2 groups.
Hi Simon,
On Tue, Oct 07, 2025 at 01:54:10PM +0200, Simon Josefsson wrote:
> Has it been discussed that /var/lock could be provided by some other
> package than systemd?
Technically speaking, /var/lock is owned by base-files. It is a symbolic
link pointing to /run/lock. So let's pretend you really asked about
/run/lock instead.
> Is there a reason the /var/lock directory MUST be provided by systemd
> and no other package could provide it?
systemd used to install /usr/lib/tmpfiles.d/debian.conf with a line
d /run/lock 1777 root root - -
overriding the systemd upstream configuration
/usr/lib/tmpfiles.d/legacy.conf containing
d /run/lock 0755 root root -
as the earlier lexicographical occurrence takes precedence. We could
have a file /usr/lib/tmpfiles.d/fhs_run_lock.conf adding this back and
it could also be installed by a different package, so yeah what you're
proposing could be a middle ground.
> Then all packages that need /var/lock in Debian can depend on this
> 'var-lock' package, which would also allow us to better track which
> packages still use this suboptimal interface for device locking. Or
> just move the directory to 'base-files' or similar.
I relate to the idea of only installing a permissive /run/lock when
there is a package that actually benefits from it. Keep in mind though
that what is being objected here is not the change itself, but the way
it is being done. Once said package exists and policy is updated to
document the additional dependency needed for obtaining FHS semantics,
systemd can go back to its restrictive /run/lock permission.
We hope that a solution is being found and that the requested reversion
is of temporary nature without imposing what that solution is.
Also keep in mind that we cannot just move packages from /var/lock based
locking to flock() based locking one at a time. If two different
packages compete about a device and they use different locking schemes,
they'll both think they had exclusive access. Going for flock()
practically needs to be a flag-day transition where all packages are
updated at roughly the same time.
Helmut
Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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