From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: Re: inxi and inxi-full Date: Fri, 13 Apr 2018 09:30:53 +0530 Message-ID: <874lkfpxfu.fsf@gmail.com> References: <87h8p0wb6m.fsf@gmail.com> <87woxwkypg.fsf@gmail.com> <874ll09kn6.fsf@gmail.com> <87po353efj.fsf@gmail.com> <877epcesqb.fsf@gmail.com> <877epcq0mg.fsf@gmail.com> <87h8og1hgi.fsf_-_@gmail.com> <87fu40pcky.fsf@gmail.com> <87woxb22o3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6ptW-0003pX-F7 for help-guix@gnu.org; Fri, 13 Apr 2018 00:01:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f6ptT-0008FC-9t for help-guix@gnu.org; Fri, 13 Apr 2018 00:01:02 -0400 Received: from mail-pl0-x22d.google.com ([2607:f8b0:400e:c01::22d]:43504) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f6ptT-0008Eg-2v for help-guix@gnu.org; Fri, 13 Apr 2018 00:00:59 -0400 Received: by mail-pl0-x22d.google.com with SMTP id a39-v6so5310912pla.10 for ; Thu, 12 Apr 2018 21:00:58 -0700 (PDT) In-reply-to: <87woxb22o3.fsf@gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Chris Marusich Cc: help-guix --=-=-= Content-Type: text/plain 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlrQK3UACgkQm9z0l6S7 zH8GOQgAr0PUJTTdWZuA7yMi1SeODjnSkL5q13j2EdjKZHXGKNmc/qyA+hdvyhmq kn16UydCSgBoVIjm3/C7d+JTW0pBSezLEyVtyX1lnu5Np4zBZSuJeLYRuDMvDau5 ZdX8mv9/RVJvux68gKXJtfeXpYuKP0mAz5YCAd2CjL1W7jzySq68GuM8sEabZg3d DZAmxk7iSttGFWFfLZz7u+nW1rpGwafCVmJWqZySJGWeNKkwubXkQF8uYbdlFFnT BfcmIusXEX6KSrzGtA+HZJ/z0u0W21hmZ87z/Xm5ywzLr7EHuBlHGIsN7Vk6EFDu oKLMDymct2VNd1GKNyqzg9AdD3FJEg== =Bg9Q -----END PGP SIGNATURE----- --=-=-=--