[kbenson]

> Note how despite not coming with the OS, `python3` is still placed in the Apple-only `/usr/bin/` directory. And a binary exists at that path either way, it's just a stub by default. Because none of this is confusing at all.

There's long been problems with this on UNIX systems. For a long time there's generally been three categories of software to track (OS provided, third party managed, manually compiled/installed), and two different locations to put them (/usr, /usr/local. / is different and has/had other constrains and reasons behind usage).

OS provided packages go into /usr, stuff a user manually compiles and installs goes into /usr/local, but where does a third party package manager put stuff? It's not OS provided, but it is packages and maintained, so /usr seems valid. At the same time, it's user installed, so /usr/local seems valid. Both make the other used of those locations more complicated to reason about.

> Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?

Possibly because some are used by the OS to actually do things for the OS (not sure if Apple finally got rid most those dependencies or not).

The problem of the OS shipping a component for it's own needs that gets used by others is a decades old problem at this point. It's complicated because if it's available users to use, they'll use it, and when the OS wants to update or change it in some way it can break user assumptions. If users update it system wide, they can break OS assumptions.

[throw0101a]

> but where does a third party package manager put stuff?

/opt

> The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition) and the Intel Binary Compatibility Standard v. 2 (iBCS2) provides for an /opt structure very similar to the one defined here.

* https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/opt.htm...

MacPorts uses /opt/local for example.

[kbenson]

Yes, that's where I would suggest putting it, but the reason projects don't is either because they aren't aware of it, feel it's a bit more convoluted to make sure you update where PATH is set, or that /opt is generally used for singular applications, not an extended hierarchy such as /opt/local (which is actually a truly weird name, /opt/macports/ with /opt/macports/bin, /opt/macports/lib, etc would make more sense). It makes sense to use /opt from an "application" point of view, but I think the problem is many of these package managers see themselves as more than that, and as pseudo-system components, which clouds their reasoning.

The LFS spec you linked to is actually ancient at version 0.65, the latest is 3.0 and available here[1]. It's a bit "do what you want", but it really expects the "local" part of /opt/local that MacPorts uses to be some sort of identifier for MacPorts.

That said, it's the Linux Filesystem Hierarchy, so it only applies to Apple stuff inasmuch as it's common practices for UNIXes in general. And it's not like the major Linux distros follow it fully either. They're happy to break from it where it preserves some historical layout their OS has had that they think is easier for their users/admins.

1: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html