From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: inxi and inxi-full Date: Thu, 12 Apr 2018 20:41:48 -0700 Message-ID: <87woxb22o3.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> 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]:43915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6pb6-0005SG-AH for help-guix@gnu.org; Thu, 12 Apr 2018 23:42:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f6pb2-0004oa-8c for help-guix@gnu.org; Thu, 12 Apr 2018 23:42:00 -0400 Received: from mail-pl0-x235.google.com ([2607:f8b0:400e:c01::235]:46466) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f6pb2-0004oD-04 for help-guix@gnu.org; Thu, 12 Apr 2018 23:41:56 -0400 Received: by mail-pl0-x235.google.com with SMTP id 59-v6so5279148plc.13 for ; Thu, 12 Apr 2018 20:41:55 -0700 (PDT) In-Reply-To: <87fu40pcky.fsf@gmail.com> (Pierre Neidhardt's message of "Thu, 12 Apr 2018 22:49:09 +0530") 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: Pierre Neidhardt Cc: help-guix --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pierre Neidhardt writes: > Oleg Pykhalov writes: > >> Pierre Neidhardt writes: >> >> What do you think about =E2=80=98inxi=E2=80=99 package with inputs, whic= h are only >> required to run it, >> and another =E2=80=98inxi-full=E2=80=99 package, which will inherit =E2= =80=98inxi=E2=80=99, 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. =20=20 * 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. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlrQJvwACgkQ3UCaFdgi Rp374g/9EMpCCWnIbRk7rwHZrCC5dt/4AjQ2jmVMNYOGyL5Z3aaqofNIrMcLhO9G HTrD4Tb0qc5KdW5IDf4rDc4xF22M46Aa9sd9E40yqYj5caUEfHXATOmtisbkoZid NFURAc1na3OvharTCqTg2U3BrJN9iV5Tm6hHlp9qgOjzrutBVLGedb0rFEuiAbYG aNe0T5C6hI2tV6SP5FQEf1fUDR1nwAlBl2nLOvJYnfD52oGmTYauHjJbOFOLPnUn lzc7VIl7nOEE16knOtXRIijla/DaVyd0AaIs7foRHvcNyEGZuEQBvZwPPOP6weZK ni7NuWa9pEqCHnovMFvJWkKn8DGtASZFEIwgjRsFBwouadZwLv87L+gi+PBX8Bm4 nx8cjrZ7x/j2QTq8CQ2HYOoHFaFfxAmhjvwXFED8oKkAcP7dT6bpt+TvpxXf8ZTT NyTKFrdKthG6VJuSMzrb3UodftzL5Hu36EPC6kE/2bBDgSSB5ef7OhfYOa55gjSe RQw077tF4r7smiBwCXSChc8sW8zmnc6d/akIJnl/JR3NdZOgHErt+01Tm12u9P2N X1IKzCWn+h8PgviXUNcPM3qAM8+ABRybl5E1qJ42J95Qr3QBAUPSKN2LyfaAL3zF VygqM9h0y66vyxMGTsxVyEgUjxX7bx0Y+ftZSk9cHKfDk5uku/Y= =V+EE -----END PGP SIGNATURE----- --=-=-=--