Helmut Grohne <helmut@subdivi.de> writes: >> 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. Thanks for explaining! Okay if this is just a one-line snippet, it seems like a lot of work, but good to know it is feasible. > 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. That seems like an archeological excursion, and I'm not sure it is the best use of everyone's time... maybe some other catch-all approach could be designed to detect when two applications are using the same device and deal with the lock problem. Or merely give up and document that for a (possibly indefinite) transition period, locking will be broken and users needs to take care of this problem themselves. This would allow partial and incremental migrations towards flock() until all application are updated. /Simon
Attachment:
signature.asc
Description: PGP signature