Pierre Neidhardt <ambre...@gmail.com> 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,

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.

[1]  https://refspecs.linuxfoundation.org/fhs.shtml

[2]  https://nixos.org/~eelco/pubs/phd-thesis.pdf


Attachment: signature.asc
Description: PGP signature

Reply via email to