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: Thu, 21 Jul 2016 22:50:20 +0200 Message-ID: <20160721205020.zg3hzpnklrg5hoeh@venom> References: <878twytwlp.fsf@gnu.org> <20160719062915.3cdpmb6xhcg3l6mw@venom> <877fchkbut.fsf@gnu.org> <20160719134245.jyk3m6cs5374bwso@crashnator.suse.cz> <20160719155024.ti4bqvenntoucgmz@crashnator.suse.cz> <20160720130559.n44vau4iysyn7qlz@crashnator.suse.cz> <87r3anedue.fsf@mdc-berlin.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="33hiflr6r7xm6f5w" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQKvM-0007B1-3J for guix-devel@gnu.org; Thu, 21 Jul 2016 16:50:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQKvI-0008MU-Or for guix-devel@gnu.org; Thu, 21 Jul 2016 16:50:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:43074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQKvI-0008LU-Ee for guix-devel@gnu.org; Thu, 21 Jul 2016 16:50:24 -0400 Content-Disposition: inline In-Reply-To: <87r3anedue.fsf@mdc-berlin.de> 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 --33hiflr6r7xm6f5w Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2016 at 07:53:45AM +0200, Ricardo Wurmus wrote: > >Tom=C3=A1=C5=A1 =C4=8Cech writes: > >> 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. > >Agreed. I think it=E2=80=99s unfortunate that there is no step in between= the >purely symbolic and the purely binary method of sharing environments. > >> 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. > >This is going to be virtually impossible. Users can change Guix >locally. We cannot assume an immutable core. Actually the condition can be this weak - there won't be any false positives, it will only make preparing reproducible builds damn hard. >Guix packages are code. Guix itself is mostly a library. That again supports the point that the code closure could gather package code only when the library will be stable and feature complete (unchanging). >> 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. > >It *can* be used for self-contained packages. =E2=80=9Cguix archive --exp= ort=E2=80=9D >and =E2=80=9Cguix archive --import=E2=80=9D is sufficient for people who c= ome from the >world of bundling. They can just take a binary archive that someone >else exported from their store and import it into their store. OK, you are right. >It is not pretty and I wouldn=E2=80=99t do it, though, because I would alw= ays >want to be able to build the exact same binaries myself, which I cannot >do without the exact same version of Guix (this includes package >expressions). > >> 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. > >In Guix we don=E2=80=99t parse package definitions. Package definitions a= re >code. A package expression is evaluated to a Scheme value. To compute >the Scheme value one needs all the definitions that are used therein. I'm aware of this. I'm not sure how lazy is evaluation in Guile but interpreter knows every pieces of this information during the execution. If the interpreter can't share this information (and there are reasons why not extend the language allowing querying the interpreter state during the execution), it would need to be done with parser, that was what I meant before (and yes, that wouldn't be elegant at all). >And that=E2=80=99s the rest of Guix. Package expressions are a part of th= e code >of Guix. The code used inside of package expressions may change as we >encounter new problems that need to be addressed. You cannot treat >package expressions as if they were apart from the rest of Guix. I think I have to just accept that. >If all you wanted was the names of all packages in a closure =E2=80=94 tha= t=E2=80=99s >easy to obtain with Guix. Just recurse over the inputs. That is apparently not enough. >But to get just a subset of Guix that is used in a closure is futile. >At the end all closures are rooted in bootstrap binaries, so it=E2=80=99s = likely >you need a big chunk of all the Guix library definitions. It=E2=80=99s ea= sier >to just include a copy of Guix itself. Right. And in the end it is not that bad solution either (until you need to use two versions of Guix at the same time). >My point is that you cannot (currently?) do this after the fact for any >store item you may want to export. You would have to embed the state of >the Guix world at store-add time in the store items themselves. This >can be done by adding the current state of Guix to the store itself and >add it as an input to each store item. This seems very heavy-handed, >though. Right. >If we agree that we don=E2=80=99t need to be able to extract the Guix stat= e for >*any* store item the problem is smaller and much easier to solve. >Preparing a reproducible binary package would then only involve >appending the current Guix state (including whatever Guix sees via >GUIX_PACKAGE_PATH) as a source archive to the exported closure. Yes, that sounds sufficiently complete and corresponds to intention - not do that automatically, not to do that for all stores, but be able to export information that when requested. I'm afraid that in that case we'll never be able to easily combine two or more exported closures together. Thank you for your patience and input into this discussion. Best regards, S_W --33hiflr6r7xm6f5w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXkTWDAAoJEEoj40+gM0Nt+DcP/iDzM41tFL6FHjlu6DUjscz/ Ciop+1KITHJupf5kIeil8bqAfK7i2ePtJBgP54iVPCmVc8BfWi2dr6rY1lEJEWU7 LixtHAKDnEPLICk8SP4epYbGluggIRk+WECE6UtqQgF3e9h6JHy6/R7kloyWLIyZ y6Gsu18tMjE40KlmqrQyfmY/JGtD49Xxqpo0rja5XVYhRpIF0/F0uaExAKQFwdCP UGJ3L8pxcUeuIQWXQREpi2QwvePBM8Ngb1KmMJ3H39JIVP8cAuNnjKPs79XFSj0R FF1ckph47eBAs80DI7GUZ4Cfm893NOU3T1Jks3mSzI0bovAQJFlTGwS1k/J+Vcor aSYfeJevW+jh425EDQxtZh+cneIc2Pkxp3gD6DxANRmapZ97U/Q1ev1oV9RwKGle quNo6yE+v/4GVSsKJvyys297TYGU8lLBihVTts/d9MqH+HKx29CcjrC698y6U1nx XYf20dTDWi3uwpW4YS52OVxHB8SY9JMBAFX8/pP2EDkZWw4ybSyuVek3DRyBcZX7 yRZyFQH3SvhQ5+G6jUwgqVhXz9gZ2yT4BJ6wjfjzw4cX/r6cKZdpt1rBXuJoiPPd aqkv85n+Gns48DscoJ7nQ7tFbstHZBYayL/O1YZW8qlFO9W+I/39WkB9uFYaDdod sQBRqp8qBaBPOw4Bqr4v =xwLa -----END PGP SIGNATURE----- --33hiflr6r7xm6f5w--