Bug#1115317: Technical Committee resolution on /var/lock and systemd

Simon Josefsson <[email protected]> Tue, 07 Oct 2025 13:54:10 +0200
Newsgroups gmane.linux.debian.devel.ctte
Message-ID <87zfa3vsf1.fsf__21548.0219035939$1759838254$gmane$org@josefsson.org>
Matthew Vernon <[email protected]> writes:

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

Has it been discussed that /var/lock could be provided by some other
package than systemd?

I agree with everything in your e-mail, but it seems entirely possible
to reach the same goal by having /var/lock be "owned" by some other
package instead of systemd, which apparently have little interest to
support /var/lock.  I can sympathise with systemd upstream on that, and
their desire to drop everything about /var/lock.  Moving ownership of
/var/lock to another package, e.g., a NEW 'var-lock' package, may be a
friendlier way forward to everyone.

Is there a reason the /var/lock directory MUST be provided by systemd
and no other package could provide it?

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.

Just an idea,
/Simon
signature.asc (application/pgp-signature, 1.2 KB)
-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmjk/2IUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFoumMAQC6475x9sn+
ogv9v82lOothu4cjOZ0V3oilYdbNVt0T5QEAmlec2CEXGpFOrPcvOlktlYEJ8Iae
gF0YTSFIxmmxlg8=
=P+/3
-----END PGP SIGNATURE-----