Pierre Neidhardt writes: > Upstream turns out to be much more complicated than expected: > > https://github.com/smxi/inxi/issues/143 I'm glad the maintainer responded so quickly! It sounds like their concerns can be summarized as follows: 1) It is a bad idea for GuixSD (and NixOS) not to follow the FHS [1]. 2) The PATH environment variable does not reliably allow inxi to find the programs it needs at runtime, so inxi does not use it. That's why inxi stores an explicit list of directories such as "/bin" in @paths and then calls check_program to find the (absolute, I think) path of a given program in that list of directories. I respect their opinion, but I think that (1) is a red herring, and (2) is incorrect. Regarding (1), I don't think it's relevant whether GuixSD and NixOS follow the FHS, but I'll voice my opinion here about why I think it makes sense for us not to do so. GuixSD follows the purely functional software deployment model. Distributions that use package managers like dpkg or rpm do not. For them, the FHS is helpful because their entire system is built on the assumption that in order to achieve correct deployment of software, their only option is to rely on the presence of impurities from the environment. The FHS is an attempt to ensure correct deployment by getting everyone to agree to install the dependencies in agreed-upon locations. In a world where relying on impurities is the norm, the FHS is certainly helpful. I would do it, too! However, because we follow the functional model, a standard like the FHS is unnecessary for us. We exercise total control over our entire dependency graph at (almost) all times. Indeed, one could even argue that a standard like the FHS is undesirable precisely because it encourages the user to rely entirely on the presence of impurities (which are not reliable!). The functional model gives us a strong guarantee for correct software deployment that we simply cannot get by following a file system hierarchy standard like the FHS. If you or the author of inxi are willing to learn more about this, then I highly encourage you to read at least the introduction (only 17 pages) of Eelco Dolstra's Ph. D. thesis [2]. The introduction succinctly outlines the problems that non-functional package managers like dpkg and rpm fail to solve, and it outlines how Nix (and thus Guix) solve those problems. After reading the introduction, I hope it will be clear why a standard like the FHS is insufficient (and even possibly an impediment) for ensuring correct deployment. Regarding (2), regardless of whether or not a distribution follows the FHS, I think any well written software should provide a mechanism to allow its users to tell it where to find the programs that it needs. It's fine for inxi to guess those locations when a user doesn't provide them, but it shouldn't deny users the ability to give it hints. The PATH environment variable is one way that a user can tell a program where its dependencies live. Users put various directories on the PATH, and then programs will find other programs by looking them up at runtime via the PATH. The author of inxi said that inxi does not rely on the PATH at all, but that is not true. Every time inxi runs Perl's "system" function to execute a program by name only (not an absolute path), it is relying on the PATH. Here's a simple example from line 292 of the script: $b_irc = ( system('tty >/dev/null') ) ? 1 : 0; Here, the "tty" program gets looked up in the PATH. The author mentioned that they are concerned that (a) PATH might not contain system programs, (b) PATH might contain irrelevant user-defined programs, and (c) PATH is sometimes not set. To each of these concerns, I would say: (a) If PATH does not contain system programs, then sure, you can try to find them by looking them up in well-known locations from the FHS. That would be a very reasonable thing to do. (b) If PATH contains user-defined programs, that's great. Some users might prefer to install their own copy of "tty" or "lspci" in a custom path. The inxi script should use that copy if the user wants it to. The PATH environment variable is one way to allow the user to do that, which is good. (c) If PATH is not set, then inxi should set it to a reasonable default (e.g., the list that is currently being used for @paths). That would be a very reasonable thing to do. In any case, in GuixSD, all we need is a way to tell inxi where it's programs live. For many programs, this is accomplished by putting the programs in PATH. If inxi wants to provide a different way for us to tell it where its programs live, that's fine. For example, if they want to provide an environment variable like "INXI_PATH", that's fine. If they want to use the Autotools to provide a "configure" script to allow us to run something like "./configure --with-lspci=path/to/my/lspci", that's fine, too. Whatever works. But it should be possible. In the world of GuixSD, we have total control over all dependencies at all times because we follow the purely functional software deployment model. As long as we define the inxi package correctly, we will never be in a situation where inxi does not find its programs. If inxi provides us a way to easily tell it where its dependencies live (e.g., PATH), then we will use it. Even if it doesn't provide an easy mechanism, we can just patch the source with explicit paths to the programs that it needs. Most software provides a mechanism for users to tell it what dependencies it should use (the PATH variable, a ./configure script, etc.), and it would be nice if inxi made it easy for its users by doing the same. > If anyone wants to chime in and try to convince the maintainer... Since you're the inxi user, I'll leave that to you. I hope I've helped by giving enough information to clarify why GuixSD departs from the FHS, and why inxi ought to let its users tell it where its dependencies live. > Otherwise we will have to go ahead and patch inxi. That is always an option. We do it all the time, so it's nothing new. Footnotes: [1] https://refspecs.linuxfoundation.org/fhs.shtml [2] https://nixos.org/~eelco/pubs/phd-thesis.pdf -- Chris