Pierre Neidhardt <ambrevar@gmail.com> writes:

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

I see.  I think we should do that if upstream takes too long or if they
are not interested in changing their software.  It shouldn't be too hard
to surgically patch these lines of code - that's all we need to do,
right?

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

If we do what you suggest, then all the "system" invocations should work
fine, but we'll still need to wrap the script so that it finds the
required Perl libraries.  For an example of how to do that, see the
definition of perl-image-exiftool in (gnu packages photo).

I'm actually a little surprised that the perl-build-system doesn't take
care of this automatically for us; we might want to fix that.  If you're
feeling ambitious, maybe you could submit a patch to add a phase to the
perl-build-system's %standard-phases that finds executable perl scripts
and wraps them automatically.

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

If the average inxi user expects that they can add and remove programs
from their environment in order to get more or less info from inxi's
reports, then I wouldn't have much of a problem with letting inxi find
the programs dynamically at runtime.  However, if that isn't the case,
I'd still prefer a static composition over a dynamic one, for the
reasons I explained earlier.

You probably know about what inxi users expect than I do, since I've
never used inxi, so ultimately I'll defer to your judgment here.

-- 
Chris