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