Pierre Neidhardt <ambre...@gmail.com> writes: > Oleg Pykhalov <go.wig...@gmail.com> writes: > >> Pierre Neidhardt <ambre...@gmail.com> 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