hope not tied to SystemD

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

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.