Re: inxi and inxi-full

[Chris Marusich]

Pierre Neidhardt <address@hidden> writes:

> The runtime dependencies are not exactly found by the PATH environment
> variable: ENV{'PATH'} is set manually and explicitly in the source.
> This is what I was discussing before (sorry if this was unclear).  Look
> at the diff I mentioned earlier.  (Or look at line ~100 in the source.)

Ah, I see that you mentioned this earlier.  Sorry for missing it!  To
resolve this issue, we could do a few things:

* Ask upstream not to manually set the PATH environment variable, which
  you mentioned in your email.

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

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.

>> If inxi-minimal can provide genuinely useful information without
>> requiring the user to install additional packages, then I think it's
>> reasonable to add a package definition for it.  However, if almost
>> everyone is going to need to install additional packages into their
>> profile just to get the output from inxi-minimal that they wanted, then
>> I think we should not add it.
>
> inxi-minimal would work.  It does provide some information.  The crucial
> part here is that the set of optional dependencies is not bound to stop,
> it could grow indefinitely.  inxi is sort of a platform for hardware
> information.
>
> Tracking them all could be hard.  

I don't think it would be too hard if we use wrap-program.  In the best
case, somebody who cares about maintaining our inxi package would just
need to add a new input to the package definition every now and then.
The benefit is that inxi installed via Guix is complete and correct.

> Besides it might make inxi's closure much bigger.  This needs testing
> though.

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.

So, I'm not too concerned about it.  But it would be good to check.

> My suggestion: let's give inxi-minimal and inxi a try, compare their
> closure size.  If it's not significant, then let's just have one single
> package.

Sounds good to me!

>> In any case, I can think of a few ways to package inxi:
>>
>> * Wrap the inxi program with wrap-program, setting its PATH, PERL5LIB,
>>   and so forth appropriately.  This seems like the easiest way to me.
>
> That would not work, see my comment above.  PATH is hardwired in the program.

If we remove from the source code the offending line that sets the PATH,
then I think wrap-program will probably work.

Thank you for taking the time to work on this.

-- 
Chris

signature.asc
Description: PGP signature