Re: inxi and inxi-full

[Pierre Neidhardt]

I've reported the issue upstream:

        https://github.com/smxi/inxi/issues/143

> * In the meantime, can't we just remove the offending line from the
>   source?  This one:
>
>   $ENV{'PATH'} = 
> 'sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin';

As I initially suggested, this would work but we also need to change
@paths to the Guix PATH values.

> None of those paths are guaranteed to exist on GuixSD.  If we remove
> that line, then won't Perl's "system" function use whatever PATH is set
> in the environment?  If, in addition to removing that line, we wrap the
> script with our wrap-program procedure, then we will have full control
> over the PATH, and inxi should work.

Why would we need to wrap the program?  With the above fix, then we are
all good, aren't we?

Or is it to ensure that inxi does not see any other binary than the one
in its wrapped environment?  Then that would prevent inxi-minimal to be
"extended" by installing more programs.

> The system, and users on the system, may have a lot of these programs
> installed already.  For example, coreutils is certainly installed
> somewhere.  It is likely that inxi's closure overlaps with some of those
> already-installed tools.  Thanks to the functional software deployment
> model that Guix follows, such overlap will automatically be
> de-duplicated in the store.

Take for instance headless systems: those won't need the full mesa stack
to get information around their graphics capabilities.

--
Pierre Neidhardt

I hold it, that a little rebellion, now and then, is a good thing...
                -- Thomas Jefferson

signature.asc
Description: PGP signature