The Debian Technical Committee, the highest Debian technical decision-making body that steps in when Debian developers can’t agree on a technical issue, has stepped in to settle a dispute between Debian developers and the systemd maintainers over the /var/lock directory.
The controversy started after a recent systemd update (version 258) made /var/lock writable only by the root user, breaking compatibility with some existing Debian software that still relies on it for system-wide locks.
However, the Technical Committee decided to overrule the systemd maintainers and require that /var/lock be restored with more relaxed permissions. According to the committee, Debian packages must continue to comply with the Filesystem Hierarchy Standard as incorporated into Debian Policy.
That means /var/lock should remain available for system-wide locks, at least until all affected software migrates to modern alternatives like flock.
The decision followed a long discussion that began with a bug report in which Debian developers raised concerns about systemd’s change. At the same time, another bug report was opened against systemd for deviating from FHS guidelines.
However, upstream systemd developers made it clear they didn’t intend to restore FHS compliance but suggested that downstream distributions could adjust permissions themselves if they wanted to.
Somewhat expectedly, Debian’s TC disagreed with that stance. “That a particular upstream is not interested in FHS compliance is not a sufficient reason for a Debian package to disregard the FHS,” the committee wrote in its resolution.
Under its constitutional authority, the TC invoked section 6.1.4 (“The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority.“) to overrule the systemd maintainers.
In other words, the directive requires that Debian’s systemd package once again grant /var/lock writable permissions so that existing software that depends on it continues to function properly.
The committee added that this arrangement should remain in place until all affected packages have been migrated to use flock or another suitable locking mechanism, and Debian Policy is updated accordingly.
For more information, see the full discussion on Debian’s mailing list.
This is another reason to start using Linux versions with other Init Systems rather than SystemD. In my case, I do much like Devuan, Gentoo and Artix. Moreover, there are other OS, such as NetBSD and OpenBSD, which, by the way, are really awesome and fabulous!
Give them an inch and they’ll take a mile…
Debian never should have adopted systemd