> Is anyone surprised that the systemd folks basically said "fuck you, we'll do what we want to" to everyone else?

I don't think that's an accurate paraphrase of "Consider this more a passing of the baton from upstream systemd to downstreams: if your distro wants this kind of legacy interface, then just add this via a distro-specific tmpfiles drop-in. But there's no point really in forcing anyone who has a more forward-looking view of the world to still carry that dir."

That kind of drop-in is pretty routine, so I don't know why this became a big thing we're all discussing now.

no, not really surprised at all

as I will explain below this change is pretty much needed sooner or later with all alternatives being noticeable worse

In addition the way Debian handles things is in a very deep conflict to how most software development is done. Like time wise not practical viable stuff like expecting small OSS teams to have LTS releases and/or back porting fixes which had been fixed with some rewrite/breaking changes. Or fun stuff like for example shipping outdated version of your software with version of dependencies it never was supposed to work with. And in the later case not only will you get bug tickets for already fixed bugs all the time (which you don't really have time for) but als bugs which should be impossible with any "supported" version(/dependency combination). As a consequence a lot of software went from "lets make sure it works with every distro" to "lets make sure it works with everything which is at least somewhat close to upstream and everything else has to figure it out themself".

Which brings us to this discussion which wasn't communicated that well:

- due to the points below it makes sense that systemd says that is is how it is going to be upstream, not open for discussion

- but it's equally reasonable for Debian to decide to prioritize more backward compatibility over bit less robustness, or at least do so for some potentially long grace period

- and systemd really should have told them about the change before they shipped it and it broke things

- but any Debian maintainer thinking they have the right to force systemd to revert the change would be very entitled

- and any systemd dev saying Debian must not revert the change in their distro is equally entitled (it's not like this is likely to cause bugs tickets against systemd which otherwise wouldn't have happened)

so a lot of bad communication. But both the decision to the change and not care about weather Debian likes it, and the decision to revert it because they don't like it, are at the core very reasonable IMHO

---

/var/lock is shared by some very core components like lvm2 and dmraid, it running out of inodes is a serious issue

In 2000 it was okay to not overly consider misbehaving user space programs, in 2025 this is relevant security issue (due to having all of 1: higher standards for resilance/reliability, 2: more malicious code, supply chain attacks etc. 3: more accidentally badly behaving code/low quality code). So this needs to be fixed.

There are 3 solutions I can come up with:

1st make no root program use /var/lock, which is a lot of work and a lot of braking changes.

2nd make /var/lock root only, considering that user programs shouldn't really use it anymore since flock (1996), XDG_RUNTIME_DIR(2003) especially since /run/user/{uid} (still 7years ago or so). So outside of breaking some minor software using an approach outdated by like 20years no issue.

3rd some crazy magical virtual file system proxy mapping entries to different temp fs instances depending on owner user id. But is that worth to have to maintain that blob of complexity which can have security vulnerability for a handful of very old software?

Only really the solution systemd did makes sense. Debian probably would love the 3rd one IFF systemd maintains it for them, so it's not really an option (Debian could still write and maintain it themself, it doesn't need any deep systemd integrations.)

So realistically speaking there is only one solution, if you don't propose a better one just saying "I don't like that, don't do that" is not going to change anything.

And systemd developers are payed by companies which need that stuff, actually most companies would want this kind of in depth increases to robustness. Because a single time of a server not hanging can easily outweighs any cost imposed by read only /var/lock (which most times will be no cost at all). Heck even Desktop systems would profit from it . And for the few systems where companies need the old /var/lock they can just change it like Debian did.

"everyone else" in this case is pretty much only the debian ecosystem because they insist on enforcing a serial lock policy from the 1980s. It's fine if Debian wants to move at the speed of a Soviet committee but I don't think it should be expected (or would be healthy) for systemd to move at the same pace.

A software developer's primary job is to develop software for their users, not to comply with a third party distributor that repackages their software.