From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: =?utf-8?Q?=E2=80=98guix_publish=E2=80=99?= now compresses archives Date: Thu, 21 Jul 2016 07:33:21 +0200 Message-ID: <87shv3eese.fsf@mdc-berlin.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQ6c3-0001Gf-23 for guix-devel@gnu.org; Thu, 21 Jul 2016 01:33:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQ6bz-0005uB-Sj for guix-devel@gnu.org; Thu, 21 Jul 2016 01:33:35 -0400 Received: from sinope02.bbbm.mdc-berlin.de ([141.80.25.24]:33875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQ6bz-0005r7-IK for guix-devel@gnu.org; Thu, 21 Jul 2016 01:33:31 -0400 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: "Thompson, David" Cc: guix-devel Thompson, David writes: > On Wed, Jul 20, 2016 at 9:05 AM, Tom=C3=A1=C5=A1 =C4=8Cech wrote: > >> 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. > > I don't really understand the point of this back-and-forth. It's > quite simple: If the user builds the same package expression with the > same version of Guix, they will get the same result if the build is > deterministic. I don't understand the contrast with Snappy and > Flatpak because they don't provide this feature at all, opting instead > to provide opaque binaries with no real provenance. I can only assume > that there is some fundamental misunderstanding about Guix going on > here. The point is that exporting a store item (or a package closure) is the moral equivalent to producing an opaque binary. The claim is that Guix could do better here. I agree to the first part but I=E2=80=99m not sure= about the second part. It would be very nice if Guix really *could* do better here without having to embed a copy of itself to each exported package. One way to do that is to provide the equivalent of a source package, i.e. exporting not only the closure but everything that=E2=80=99s needed = to build it yourself (including the source archives of all involved packages and all package expressions and all of the supporting Guix library features). The weaker proposition is to embed some metadata (such as the exact version of Guix upstream and a list of packages, but this would not be sufficient as Guix can be modified and GUIX_PACKAGE_PATH would not be included). ~~ Ricardo