Re: inxi and inxi-full

[Pierre Neidhardt]

Chris Marusich <address@hidden> writes:

> If we make two package definitions, I would prefer the name
> "inxi-minimal" for the version that is statically composed with the bare
> minimum of its runtime dependencies.  This is similar to how we have
> named other "minimal" packages in the past (e.g., qemu-minimal).

OK.

> I've taken a peek at inxi.  I assume it's this:
>
> https://github.com/smxi/inxi

Yes, sorry for not providing the link earlier.

> I see that it's a single perl script.  It runs various programs via
> Perl's "system" function in order to collate information about the
> system, and it then reports the results.  These programs - the runtime
> dependencies - are found via the PATH environment variable.  The script
> also embeds paths in some places that might need to be fixed.  For
> example, it looks like the get_gcc_data subroutine searches for gcc
> executables in the /usr/bin directory, which will not exist on GuixSD.

Thank you for the pointer to get_gcc_data.

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

> 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.  Besides it might make inxi's closure
much bigger.  This needs testing though.

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.


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

> * Patch the absolute paths in the source with a patch file, a snippet,
>   or an extra build phase.

This would be a lot of hard work: the file is 16k+ lines, `system` calls
are all over the place and lots of variable names contain the program
names in question (e.g. `my @xdpyinfo`), which prevents global substitutions.

> * Ask the maintainer (or submit a patch to them) to provide a mechanism
>   to explicitly tell inxi where its dependencies live (e.g., some kind
>   of configure script), and then use that mechanism.  This seems like
>   the hardest way to me, but it is also the most ideal.

Or ask the maintainer not to manually set the PATH variable.
I'll report the issue on GitHub.

--
Pierre Neidhardt

Five bicycles make a volkswagen, seven make a truck.
                -- Adolfo Guzman

signature.asc
Description: PGP signature