hope not tied to SystemD

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

But the point is, the standard is specifying mechanism. It shouldn't - it should be specifying policy.

If 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? Yes yes real world cough cough it doesn't always work ... but that is a pretty blatant failure of the standards process!

Cheers,
Wol

hope not tied to SystemD

Posted Aug 17, 2025 14:55 UTC (Sun) by bluca (subscriber, #118303) [Link] (10 responses)

> But the point is, the standard is specifying mechanism. It shouldn't - it should be specifying policy.

No, it mentions whatever we find useful to mention and is in scope. And for normal users this is useful information.

If it offends the feelings of a couple of antis, well, they'd be offended anyway, so why bother and make things worse for nearly everyone in a futile attempt to satisfy a handful of loudmouths who will never be satisfied anyway? Makes zero logical sense

hope not tied to SystemD

Posted Aug 17, 2025 18:18 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (9 responses)

Please stop putting words in my mouth. I never said there was anything wrong with mentioning systemd. I'm simply of the opinion that systemd should not be described as the one and only way of obtaining a specific piece of information, as it makes all non-systemd distros inherently non-compliant with the spec. That would be fine if this was a systemd spec, but it is a UAPI spec.

hope not tied to SystemD

Posted Aug 17, 2025 20:25 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

What's the organisation that refused to standardise anything unless there were TWO independent implementations?

As I said before, we screamed blue murder about the amount of Office XML stuff that was defined as "what Office 95 does". Why are we now doing exactly the same thing and defining something as "what systemd does".

And again as I said, do we want to give any Tom Dick or Harry the power to change the defined standard - quite possibly without realising that's what they're doing - just by submitting a bugfix or enhancement to the definition?

It's shades of the C specification saying "we defer to the platform standard", when the Posix platform standard says "we defer to the official C specification". The end result is a definition that cannot be trusted to (a) be easily understood, and (b) to be trusted to remain (mostly) immutable.

Cheers,
Wol

hope not tied to SystemD

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

> As I said before, we screamed blue murder about the amount of Office XML stuff that was defined as "what Office 95 does". Why are we now doing exactly the same thing and defining something as "what systemd does".

Putting aside the minor detail that "the amount" referenced above was actually just _once_ [1], there is a _major_ difference between saying "do what <proprietary undocumented thing> does" and "do what <a heavily-documented component of a Free Software tool that ~98.76% of the intended audience has been using for over a decade> does"

[1] 2.15.3.26 footnoteLayoutLikeWW8

hope not tied to SystemD

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

> as it makes all non-systemd distros inherently non-compliant with the spec

No? The spec is about directories. Tools are not part of it, they are useful ancillary information. The spec is called "Linux Filesystem Hierarchy" not "tools to print directories"

hope not tied to SystemD

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

The spec says that the only way to discover the location of /usr/lib/arch-id is to run a systemd command, as I said upthread[1]. No alternative is provided, so on systems that lack systemd, there is simply no specification of where this directory is located or how to find it. The same also goes for the .../lib/arch-id subdirectories in other parts of the filesystem.

[1]: https://lwn.net/Articles/1034093/

hope not tied to SystemD

Posted Aug 18, 2025 8:02 UTC (Mon) by gdiscry (subscriber, #91125) [Link]

The spec says that arch-id in $libdir is an architecture tuple:

The architecture identifier to use is defined on Multiarch Architecture Specifiers (Tuples) list.

The issue is that some distributions do not use that path:

Legacy locations of $libdir are /usr/lib/, /usr/lib64/.

Therefore, systemd-path is currently one way to query the path of $libdir at runtime across distributions that use systemd.

You could also use the first existing directory:

/usr/lib/arch-id/
/usr/lib64/ (if your architecture is x86_64)
/usr/lib/

hope not tied to SystemD

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

> The spec says that the only way to discover the location of /usr/lib/arch-id is to run a systemd command

No, it doesn't say it's the only way. It provides that as a way to do that, which works in 99.999% of the cases.

hope not tied to SystemD

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

> No, it doesn't say it's the only way.

Can we please drop the silly word pedantry? If the spec describes one and only one way to do something, and gives not the slightest hint that that way will not work in all circumstances, then supporting that method is a requirement of the spec. I'm baffled that you are continuing to argue this point.

hope not tied to SystemD

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

Once again, there is no requirement for any particular tool, it's just a description of a hierarchy of directories, and that's the end of it. Any requirement for any particular tool is a misreading, intentional or not.

hope not tied to SystemD

Posted Aug 18, 2025 17:46 UTC (Mon) by daroc (editor, #160859) [Link]

I think neither of you are likely to change each other's minds at this point. Let's leave the discussion here, please.

hope not tied to SystemD

Posted Aug 17, 2025 14:56 UTC (Sun) by pizza (subscriber, #46) [Link] (15 responses)

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