Re: inxi and inxi-full

[Chris Marusich]

Pierre Neidhardt <address@hidden> writes:

> Oleg Pykhalov <address@hidden> writes:
>
>> Pierre Neidhardt <address@hidden> writes:
>>
>> What do you think about ‘inxi’ package with inputs, which are only
>> required to run it,
>> and another ‘inxi-full’ package, which will inherit ‘inxi’, but with
>> additional inputs?

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

> My first thought is that it sounds like a good alternative to the
> concept of optional dependencies.
>
> I like the idea.
>
> It also means that the `inxi` package cannot patch inxi with full store
> paths.
>
> Any suggestion other than making leaving ENV{'PATH'} untouched and
> setting @paths to it?

I've taken a peek at inxi.  I assume it's this:

https://github.com/smxi/inxi

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.

Let's suppose that we go ahead and create an "inxi-minimal" package that
only contains just enough inputs to get the tool to run, and we also
allow it to dynamically find tools at runtime via the PATH environment
variable.  Will inxi-minimal be useful for someone who wants to run
inxi?  Or is it more likely that someone will install inxi-minimal, run
it, find out that it didn't report all the info they expected it to
print (because they happened to not have some of the tools available in
their PATH), and then they will eventually realize they need to install
more packages in order for inxi to make use of them?

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.  In any case, we should definitely have an
"inxi" package that is statically composed with as many of its runtime
dependencies as are required to make the tool useful by default.  Maybe
we can even add an "inxi-full" package that is statically composed with
as many of its runtime dependencies as possible, for those who need inxi
to report even more information.

I believe that whenever we can avoid it, we should not require a user of
Guix to manually compose software together at runtime by manually
installing additional packages.  I believe this is true even when the
software in question assumes (like inxi tacitly does) that that is how
most people will want to compose the software with its runtime
dependencies.  This sort of runtime composition may be useful or even
unavoidable in certain cases (e.g., when a program uses the EDITOR
environment variable to run the user's preferred text editor), but it
can result in incomplete or incorrect deployment, so we should avoid it
when we can.

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.
  
* Patch the absolute paths in the source with a patch file, a snippet,
  or an extra build phase.

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

I would be happy with any of those approaches.  I just want to make sure
that whatever we add, we don't burden most users by requiring them to
install additional packages just to make inxi work the way they wanted.

-- 
Chris

signature.asc
Description: PGP signature