Re: inxi and inxi-full
Chris Marusich writes: > If you or the > author of inxi are willing to learn more about this, I hope you did not think I was on the inxi's maintainer's side! :p I understand and agree with all your points. >> If anyone wants to chime in and try to convince the maintainer... > > Since you're the inxi user, I'll leave that to you. I hope I've helped > by giving enough information to clarify why GuixSD departs from the FHS, > and why inxi ought to let its users tell it where its dependencies live. Considering the maintainer's latest comments, I don't think he/she is open to discussion. It's too bad because I do not know any good alternative to inxi. Maybe it's time to solve this conky/i3status/inxi mess and roll out a Lisp-programmable/extensible monitor/reporter. What do you people think? >> Otherwise we will have to go ahead and patch inxi. > > That is always an option. We do it all the time, so it's nothing new. I'll go ahead then. -- Pierre Neidhardt Nonsense. Space is blue and birds fly through it. -- Heisenberg signature.asc Description: PGP signature
Re: inxi and inxi-full
Pierre Neidhardt writes:
> Upstream turns out to be much more complicated than expected:
>
> https://github.com/smxi/inxi/issues/143
I'm glad the maintainer responded so quickly! It sounds like their
concerns can be summarized as follows:
1) It is a bad idea for GuixSD (and NixOS) not to follow the FHS [1].
2) The PATH environment variable does not reliably allow inxi to find
the programs it needs at runtime, so inxi does not use it. That's
why inxi stores an explicit list of directories such as "/bin" in
@paths and then calls check_program to find the (absolute, I think)
path of a given program in that list of directories.
I respect their opinion, but I think that (1) is a red herring, and (2)
is incorrect.
Regarding (1), I don't think it's relevant whether GuixSD and NixOS
follow the FHS, but I'll voice my opinion here about why I think it
makes sense for us not to do so. GuixSD follows the purely functional
software deployment model. Distributions that use package managers like
dpkg or rpm do not. For them, the FHS is helpful because their entire
system is built on the assumption that in order to achieve correct
deployment of software, their only option is to rely on the presence of
impurities from the environment. The FHS is an attempt to ensure
correct deployment by getting everyone to agree to install the
dependencies in agreed-upon locations. In a world where relying on
impurities is the norm, the FHS is certainly helpful. I would do it,
too!
However, because we follow the functional model, a standard like the FHS
is unnecessary for us. We exercise total control over our entire
dependency graph at (almost) all times. Indeed, one could even argue
that a standard like the FHS is undesirable precisely because it
encourages the user to rely entirely on the presence of impurities
(which are not reliable!). The functional model gives us a strong
guarantee for correct software deployment that we simply cannot get by
following a file system hierarchy standard like the FHS. If you or the
author of inxi are willing to learn more about this, then I highly
encourage you to read at least the introduction (only 17 pages) of Eelco
Dolstra's Ph. D. thesis [2]. The introduction succinctly outlines the
problems that non-functional package managers like dpkg and rpm fail to
solve, and it outlines how Nix (and thus Guix) solve those problems.
After reading the introduction, I hope it will be clear why a standard
like the FHS is insufficient (and even possibly an impediment) for
ensuring correct deployment.
Regarding (2), regardless of whether or not a distribution follows the
FHS, I think any well written software should provide a mechanism to
allow its users to tell it where to find the programs that it needs.
It's fine for inxi to guess those locations when a user doesn't provide
them, but it shouldn't deny users the ability to give it hints. The
PATH environment variable is one way that a user can tell a program
where its dependencies live. Users put various directories on the PATH,
and then programs will find other programs by looking them up at runtime
via the PATH.
The author of inxi said that inxi does not rely on the PATH at all, but
that is not true. Every time inxi runs Perl's "system" function to
execute a program by name only (not an absolute path), it is relying on
the PATH. Here's a simple example from line 292 of the script:
$b_irc = ( system('tty >/dev/null') ) ? 1 : 0;
Here, the "tty" program gets looked up in the PATH. The author
mentioned that they are concerned that (a) PATH might not contain system
programs, (b) PATH might contain irrelevant user-defined programs, and
(c) PATH is sometimes not set. To each of these concerns, I would say:
(a) If PATH does not contain system programs, then sure, you can try to
find them by looking them up in well-known locations from the FHS.
That would be a very reasonable thing to do.
(b) If PATH contains user-defined programs, that's great. Some users
might prefer to install their own copy of "tty" or "lspci" in a
custom path. The inxi script should use that copy if the user wants
it to. The PATH environment variable is one way to allow the user
to do that, which is good.
(c) If PATH is not set, then inxi should set it to a reasonable default
(e.g., the list that is currently being used for @paths). That
would be a very reasonable thing to do.
In any case, in GuixSD, all we need is a way to tell inxi where it's
programs live. For many programs, this is accomplished by putting the
programs in PATH. If inxi wants to provide a different way for us to
tell it where its programs live, that's fine. For example, if they want
to provide an environment variable like "INXI_PATH", that's fine. If
they want to use the Autotools to provide a "configure" script to allow
us to run something like "./configure --with-lspci=path/to/my/lspci",
that's fine, too. Whatever works.
Re: inxi and inxi-full
Upstream turns out to be much more complicated than expected: https://github.com/smxi/inxi/issues/143 If anyone wants to chime in and try to convince the maintainer... Otherwise we will have to go ahead and patch inxi. -- Pierre Neidhardt signature.asc Description: PGP signature
Re: inxi and inxi-full
Chris Marusich writes: >> 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). OK. > 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. Sadly, I know next to nothing about Perl. I'd rather leave this to someone with some Perl knowledge. > 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. Yes, inxi makes it very clear that it can be composed dynamically. This is precisely how it's used on most major distributions I think. https://aur.archlinux.org/packages/inxi/ Cf. the documentation and the `inxi --recommends` output. -- Pierre Neidhardt Mirrors should reflect a little before throwing back images. -- Jean Cocteau signature.asc Description: PGP signature
Re: inxi and inxi-full
Pierre Neidhardt 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
signature.asc
Description: PGP signature
Re: inxi and inxi-full
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.
> 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
signature.asc
Description: PGP signature
Re: inxi and inxi-full
Pierre Neidhardt 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
Re: inxi and inxi-full
Chris Marusich 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
Re: inxi and inxi-full
Pierre Neidhardt writes:
> Oleg Pykhalov writes:
>
>> Pierre Neidhardt 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
Re: inxi and inxi-full
Oleg Pykhalov writes:
> Pierre Neidhardt 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?
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?
--
Pierre Neidhardt
There is more to life than increasing its speed.
-- Mahatma Gandhi
signature.asc
Description: PGP signature
inxi and inxi-full
Pierre Neidhardt 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? Oleg. signature.asc Description: PGP signature
