From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Introducing =?utf-8?B?4oCYZ3VpeCBwYWNr4oCZ?= Date: Sun, 12 Mar 2017 17:56:05 +0100 Message-ID: <87d1dm304a.fsf@gnu.org> References: <87d1dodcnb.fsf@gnu.org> <87mvcred6y.fsf@gmail.com> 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]:37733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cn6mz-0006X6-Dx for guix-devel@gnu.org; Sun, 12 Mar 2017 12:56:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cn6mw-0005Ds-Cd for guix-devel@gnu.org; Sun, 12 Mar 2017 12:56:13 -0400 In-Reply-To: <87mvcred6y.fsf@gmail.com> (Chris Marusich's message of "Sat, 11 Mar 2017 13:05:57 -0800") 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: Chris Marusich Cc: Andy Wingo , guix-devel Hi Chris, Chris Marusich skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: [...] >> lrwxrwxrwx root/root 0 1970-01-01 01:00 ./gnu/store/ynafk7v924xi= l993dqbx4mxxnm9ifsi6-profile/bin/guild -> /gnu/store/62hqgi4cac0f70v1ycsvv9= 85fl3l1hzr-guile-next-2.1.7/bin/guild > > Why does a relative path ./gnu/store/... point to an absolute path > /gnu/store/...? I would have thought it would be "relative to > relative", or "absolute to absolute", not "relative to absolute". > Perhaps I'm missing something. > > What is the expected method for extracting the tarball? Can you 'cd' to > any directory and run a command like 'tar -xf the_file', or does the > current working directory have to be '/'? The extraction method is supposed to be the same as for the Guix binary tarball, since it=E2=80=99s exactly the same code: https://gnu.org/software/guix/manual/html_node/Binary-Installation.html >> I=E2=80=99d like to move support for Docker (currently in =E2=80=98guix = archive=E2=80=99) to >> this new command because I think it=E2=80=99s more appropriate: =E2=80= =98guix archive=E2=80=99 >> is supposed to be rather low-level so it would not create a profile, for >> instance. > > My understanding is that one use case for this command is to make it > easy to deploy software (and the closure of its dependencies) using > Docker, in the case (maybe always? I'm not too familiar with Docker) > where you cannot run Guix inside of the Docker instance. If you could > run Guix, I imagine you would not need this solution, since you could > just install it via the usual Guix mechanisms (e.g., 'guix package -i > foo'). > > Another use case seems to be specifically the creation of a tarball > containing Guix to enable a binary installation of it (you mentioned > that was the inspiration for this feature). > > What other use cases do you imagine? Is the intent to make it easy to > deploy software (and the closure of its dependencies) to any place where > you either can't or don't want to install Guix first? The use case for =E2=80=98guix archive -f docker=E2=80=99 (which already ex= ists; I=E2=80=99m just proposing to move it to =E2=80=98guix pack=E2=80=99) is when you=E2=80= =99d like to pass software to someone who has Docker but not Guix: https://lists.gnu.org/archive/html/guix-devel/2017-01/msg00048.html I think the impetus for Ricardo was when the Emacs folks were discussing of building Docker images of Emacs. :-) But I guess it=E2=80=99s not uncommon for people to have Docker and not Gui= x, as sad as it may sound. ;-) >> (define* (self-contained-tarball name profile >> #:key deduplicate?) >> "Return a self-contained tarball containing a store initialized with t= he >> closure of PROFILE, a derivation. The tarball contains /gnu/store, /var= /guix, >> and PROFILE is available as /root/.guix-profile." > > Why is it necessary to include /var/guix? I'm thinking about the case > where you're using this to package something other than Guix, e.g., some > other piece of software for deployment in a Docker instance. FTR, this code was in (gnu system install) until now where it was used to create the Guix standalone tarball. For the Guix binary tarball, it=E2=80=99s important to have /var/guix with = the store database properly initialized and so on. For other cases, it=E2=80=99s probably less useful. We could make it optio= nal. >> ;; Note: there is not much to gain here with deduplication and >> ;; there is the overhead of the '.links' directory, so turn it >> ;; off. >> (populate-single-profile-directory %root >> #:profile #$profile >> #:closure "profile" >> #:deduplicate? #f) > > When you say "there is not much to gain here," do you mean "it is > unlikely that duplication will occur"? If so, why is that true? In the Guix binary tarball, there are few files present several times, hence =E2=80=9Cnot much to be gained.=E2=80=9D Back then I compared both a= nd the deduplicated version was about the same size as the other one, IIRC. But again, for the more general case, I agree it would make sense to have an option for this. I=E2=80=99ve pushed =E2=80=98guix pack=E2=80=99 in commit 239c22663ac928618028c4ec03cefc77de788e9d (slightly improved version of what I posted.) Still many ways in which we can improve it! The Docker backend requires a bit of thought because of the dependency on libgcrypt and guile-json, which =E2=80=98gexp->derivation=E2=80=99 doesn= =E2=80=99t yet handle nicely. Thanks for your feedback! Ludo=E2=80=99.