[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inxi and inxi-full

From: Pierre Neidhardt
Subject: Re: inxi and inxi-full
Date: Fri, 13 Apr 2018 11:22:55 +0530
User-agent: mu4e 1.0; emacs 26.1

I've reported the issue upstream:

> * 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

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]