hope not tied to SystemD

Posted Aug 17, 2025 14:56 UTC (Sun) by pizza (subscriber, #46)
In reply to: hope not tied to SystemD by Wol
Parent article: Finding a successor to the FHS

> I read THE STANDARD, and my system does not provide systemd and its assorted bits and pieces, then I'm up a gum tree. Isn't the point of standards to avoid such gum tree messes?

Uh, the entire point of a specification is to define minimum requirements, and by definition, if you don't meet those, you're SoL.

hope not tied to SystemD

Posted Aug 17, 2025 20:35 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (14 responses)

If systemd is required to comply with the standard, then they probably should not have given it to the UAPI folks in the first place.

(I say this as someone who likes and uses systemd. My position is not that systemd should be removed from the standard, merely that systemd should not be part of the minimum requirements for a standard that wishes to be universal.)

hope not tied to SystemD

Posted Aug 17, 2025 21:16 UTC (Sun) by pizza (subscriber, #46) [Link] (4 responses)

> My position is not that systemd should be removed from the standard, merely that systemd should not be part of the minimum requirements for a standard that wishes to be universal.

"Universality" only extends out to the scope of what you're trying to achieve.

A truly "universal standard" would necessarily need to include the likes of Windows, MacOS/iOS, zOS, and so forth... good luck finding common ground there. Just like it is reasonable to reduce the scope of said "universality" to exclude non-UNIXes, it's reasonable to exclude non-Linuxes. But even sticking to "Linux", it's reasonable to exclude Android and purpose-built embedded systems... and oh look, we're already quibbling over where the outer bounds are drawn.

In this specific instance, excluding systemd-udev by name makes little sense given that it is the canonical implementation of /dev management under Linux, and independent re-implentations [1] have to behave in the same manner or fail the basic fitness-for-purpose test.

[1] all one of them (ie busybox) -- There's also eudev, but it was forked from pre-residing-in-systemd's-git-repo udev for entirely political [2] reasons.
[2] "We don't want to have any source code from systemd present even if the udev binary produced has zero runtime dependencies on systemd"

hope not tied to SystemD

Posted Aug 17, 2025 22:26 UTC (Sun) by Wol (subscriber, #4433) [Link] (3 responses)

> it's reasonable to exclude non-Linuxes. But even sticking to "Linux", it's reasonable to exclude Android and purpose-built embedded systems... and oh look, we're already quibbling over where the outer bounds are drawn.

Well, I run a mainstream (at least, last I knew it was used by kernel devs like Greg KH) distro, and I had to change the init system away from the default, and to systemd. (And yes, I do describe gentoo as somewhat systemd-hostile, but the distro devs prefer OpenRC which I believe predates systemd, so it's not a case of "we refuse to have systemd", just "we don't see the benefit in changing". I don't agree, but I'm not a distro dev, and I've taken advantage of the ability to change the default.)

Any spec that is intended to be a reference for ALL "typical" linux distros should not defer to what just SOME of those distros do. A proper superset should not be defined in terms of a subset - it's just the wrong thing to do.

To put it in your terms, if the spec writers intend it to apply to "all linux distros", or even "all linux distros with typical user spaces like Gnome or KDE/Plasma, then they have extended the boundaries of the spec beyond systemd-distros, so they cannot assume the presence of systemd on the system.

Cheers,
Wol

hope not tied to SystemD

Posted Aug 17, 2025 22:33 UTC (Sun) by bluca (subscriber, #118303) [Link] (2 responses)

> they cannot assume the presence of systemd on the system

quote the parts where that is the case

hope not tied to SystemD

Posted Aug 18, 2025 7:07 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

So you clearly didn't read the comment you were replying to.

My distro, by default, does NOT install systemd, therefore you cannot assume its presence on my system (yes it does happen to be there, I over-rode the default, but the choice is either/or, not both/and).

Cheers,
Wol

hope not tied to SystemD

Posted Aug 18, 2025 8:51 UTC (Mon) by bluca (subscriber, #118303) [Link]

...and? What has that to do with anythng written there?

hope not tied to SystemD

Posted Aug 17, 2025 22:13 UTC (Sun) by bluca (subscriber, #118303) [Link] (8 responses)

> If systemd is required to comply with the standard

Can you quote the parts that where that is the case?

hope not tied to SystemD

Posted Aug 18, 2025 3:41 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (7 responses)

As I explained to you in another subthread, I already quoted that part of the spec upthread: https://lwn.net/Articles/1034093/

To be clear, this is not "optional" or ancillary information. It is the only way to discover the path to one of the specified directories.

hope not tied to SystemD

Posted Aug 18, 2025 8:50 UTC (Mon) by bluca (subscriber, #118303) [Link] (6 responses)

You are mistaken, this is most definitely optional and ancillary information.

hope not tied to SystemD

Posted Aug 18, 2025 9:26 UTC (Mon) by rschroev (subscriber, #4164) [Link]

If it is meant as optional and ancillary information, might I suggest rewriting it?

"Instead of constructing the arch-id and $libdir manually, you can query $libdir for the primary architecture of the system by invoking systemd-path system-library-arch on systems that support it". Or something similar.

The way it is written now, very much gives the impression that invoking systemd-path system-library-arch is the one and only way.

hope not tied to SystemD

Posted Aug 18, 2025 17:27 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (4 responses)

In a spec that describes the layout of the filesystem, the path to one of the specified directories is not "ancillary" information. It is a core part of the spec.

hope not tied to SystemD

Posted Aug 18, 2025 17:41 UTC (Mon) by bluca (subscriber, #118303) [Link] (3 responses)

The path is not related in any way, shape or form to any tool. It's distribution and architecture dependent, and that's why there's a convenience utility available.

I assure you that out of ~60000 packages building right now in Debian, and however many are in Ubuntu, exactly _zero_ use systemd-path to query the library directory at build time. A significant fraction of those _will_ need to explicitly know what the exact path is, and they won't use that tool for it.

It's just a utility provided for convenience, it is not part of any specification.

hope not tied to SystemD

Posted Aug 21, 2025 7:06 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

> it is not part of any specification.

Good, then you should have no objection to rewording that sentence in a way that clarifies it is non-normative.

I'm glad we're in agreement on that much, at least.

hope not tied to SystemD

Posted Aug 21, 2025 10:15 UTC (Thu) by bluca (subscriber, #118303) [Link]

Feel free to send a PR to adjust any wording of any sentence of any paragraph, and it will be discussed in its own merit

hope not tied to SystemD

Posted Aug 21, 2025 10:14 UTC (Thu) by bluca (subscriber, #118303) [Link]

> I assure you that out of ~60000 packages building right now in Debian, and however many are in Ubuntu, exactly _zero_ use systemd-path to query the library directory at build time. A significant fraction of those _will_ need to explicitly know what the exact path is, and they won't use that tool for it.

This is not a hyperbole btw, I really mean it.

Number of packages calling systemd-path in debian/rules to find per-arch libdir: zero out of 30000

https://codesearch.debian.net/search?q=path%3Adebian%2Fru...

Number of packages using at least one other mean (a specific makefile include file that defines a specific makefile var, none of which are related to systemd): ~5000 out of ~30000

https://codesearch.debian.net/search?q=path%3Adebian%2Fru...