From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?VG9tw6HFoSDEjGVjaA==?= Subject: Re: =?utf-8?B?4oCYZ3VpeCBwdWJsaXNo?= =?utf-8?B?4oCZ?= now compresses archives Date: Wed, 20 Jul 2016 15:05:59 +0200 Message-ID: <20160720130559.n44vau4iysyn7qlz@crashnator.suse.cz> References: <878twytwlp.fsf@gnu.org> <20160719062915.3cdpmb6xhcg3l6mw@venom> <877fchkbut.fsf@gnu.org> <20160719134245.jyk3m6cs5374bwso@crashnator.suse.cz> <20160719155024.ti4bqvenntoucgmz@crashnator.suse.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pkclj72eqldzbiel" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPrCP-0007XO-5D for guix-devel@gnu.org; Wed, 20 Jul 2016 09:06:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPrCM-0007AU-B8 for guix-devel@gnu.org; Wed, 20 Jul 2016 09:06:05 -0400 Received: from mx2.suse.de ([195.135.220.15]:35002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPrCL-0007AG-VV for guix-devel@gnu.org; Wed, 20 Jul 2016 09:06:02 -0400 Content-Disposition: inline In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org --pkclj72eqldzbiel Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 01:20:26PM +0200, Ricardo Wurmus wrote: > >Tom=C3=A1=C5=A1 =C4=8Cech writes: > >> On Tue, Jul 19, 2016 at 04:23:14PM +0200, Ricardo Wurmus wrote: >>> >>>Tom=C3=A1=C5=A1 =C4=8Cech writes: >>> >>>> Imagine situation where person A is running some distribution with >>>> Guix package manager on top and has some set of his personal packages >>>> containing additional patches which are not part of Guix GIT. >>>> >>>> He'd like to share the package with person B, running different >>>> distribution with Guix package manager at different revision on top, >>>> with different set of personal packages and alterations. >>>> >>>> I'd like to provide them a way, how to pass from person A to person B >>>> some binary archive in a way that he could understand (and verify) >>>> what he received. If it requries out-of-tree package definitions of >>>> person A, patches, etc, bundle it together. >>> >>>This is already possible with =E2=80=9Cguix archive --export=E2=80=9D an= d =E2=80=9C--import=E2=80=9D. >>> ... >>>What=E2=80=99s not so nice about this is that you can end up with binari= es in >>>your store that you cannot rebuild yourself (because you never had the >>>sources to begin with). (I wonder if this has implications on software >>>freedom.) >>> >>>~~ Ricardo >>> >> >> Ooops, I answered to Ricardo only... >> >> Yes, you can take exported archive (optionally with it's dependencies >> - --recursive) and add it to the person B's store. That is comparable >> to tarball (and making Guix aware of new items in store). >> >> The thing that you can't rebuild the binaries is exactly my point, >> because person A knows how to build it, but person B does not. Thanks! > >Are you suggesting that package archives and store exports must include >all package expressions (and all supporting code to build them) needed >to reproduce them? The store can hold packages that were built with >different versions of Guix. Does this mean that each version of Guix >that has been used should also be kept in the store? First, I'm not saying that we should do that for every archive, but I think that having a way how to automatically export this information would be great and I see it as a week point for using Guix packages as alternative to Snappy or Flatpak. Now, as long as Guix sources are part of equation and change during the time, you may need to keep more Guix versions. If there is some stable not-changing core, you probably could eliminate the need. >But wait, this goes even further than just versions of Guix. There may >be stuff in the GUIX_PACKAGE_PATH. Are you suggesting that all of this >should become part of package archives? This doesn't sound like tougher problem than the rest - you have separate package definitions. It means just more data to process. (that doesn't mean that problem is easy to solve) >If so: how? 1] I guess I should better explain my position. In the discussion on social media I was explaining why it can't be used now for self-containing packages and what is missing. My goal now on the mailing list is here the discussion itself, to see whether it is possible and whether are people interested in that. 2] I don't know much Guile, maybe there is nice way how to work with Scheme program from Scheme program. If I should implement it, I'd need to strictly "draw line" between package definitions and Guix itself, then I would need to parse package definitions files to identify which parts were used and ship those. Maybe you can get this information during evaluation by some side effect. I don't know Guile enough, really. S_W --pkclj72eqldzbiel Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXj3crAAoJEEoj40+gM0NtCzsP/1gv26PWsOglaT6Q9ba/P/zI uaxJkz8NhSrdGRX63I4fGO9g/6FpQv8Dtxu64FzwTheAE6DsdsBzlbi6gpiXamro Mw/Z3+KFDBqFhKCPofAJAO2C+LOxiOvPsdf88EGzh0UnSnXtMgUNrRba9GOsXuAQ GuFJV4Hjc4Q1xJZPRlXjcHzASw7vFtS+Viitz1JHnaDMOqoCcu9u2TqGSAJPOxL6 SlxK18ZklYFQnXDAt/eqnlADraCrGIQHIeCVLexguxQmRpyoeLdJPZOfdwIdwsXf sqfFzVygSr1+ccoHF2ujo51I/eGLrGIufccBWWov6fk/Sm+BmumV9eEDZXZ89kxD /XuhMdTs92SOyOr0XLNUOv0ik+coYPx3NW3HU2yQjuf9kTpgzzedZ7Eylq5L5OW8 4paBN53zGAvvc587PVgOd/ROx3zOvL6KAYzjaq4fNmCdv0YsrXSFC7LhsUAXc9KS g5ll+LILkV5UzreEakOqvkLpZpqUjZcJmTdInhXzA9qZnID3qI9/0tsHjzWfnufu QKUTfjvD8ynKkXs41hAhNZRge48N44VlmsLE5lD2ht/EJ9+Gv+HGm3/BeyZO9Psm ZMB7PvdUDpzJXhFiP2ql8lQTJk/Vto0a/ZPWx+B+n0m8wdYHWJ7HATAmUIc+X5Fn IUvU/I3fxuZG2DZypIi2 =Va/b -----END PGP SIGNATURE----- --pkclj72eqldzbiel--