From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Hinsen Subject: Re: Reproducible environments Date: Tue, 6 Oct 2015 18:59:44 +0200 Message-ID: <22035.65024.910687.992427@Konrad-Hinsens-MacBook-Pro-2.local> References: <22035.42892.444833.212704@Konrad-Hinsens-MacBook-Pro-2.local> <20151006120043.GB11759@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjVai-0004z8-Ku for guix-devel@gnu.org; Tue, 06 Oct 2015 12:59:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjVae-0004Qm-D5 for guix-devel@gnu.org; Tue, 06 Oct 2015 12:59:52 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:56238) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjVae-0004Qe-46 for guix-devel@gnu.org; Tue, 06 Oct 2015 12:59:48 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D9510207D3 for ; Tue, 6 Oct 2015 12:59:47 -0400 (EDT) In-Reply-To: <20151006120043.GB11759@thebird.nl> 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Pjotr Prins , guix-devel@gnu.org Hi Pjotr, First of all, thanks for your explanations! > At this point (correct me if I am wrong), the route to take is to > checkout a commit of the Guix source tree (with packages). The SHA > value is captured on Hydra in the build itself. That is the only way > to fully reproduce GUIX as a point in time. And use guix package using > that tree. OK, so the procedure is: 1) Check out a specific commit of Guix. 2) Make a manifest that defines a profile 3) Use "guix package" with options -p for defining the profile -L for pointing to the directory containing the package descriptions -m for choosing the manifest I could then archive 1) and 2) for reproducing the environment later. That sounds quite doable. > > Problem #2: What if my profile contains packages from several > > Guix commits (typically for getting specific older versions)? Or > > if it contains packages defined outside of the Guix distribution, > > in Guile modules on GUIX_PACKAGE_PATH? > > You'd have to create a new profile that is tied to above build to be > fully reprocible. Managing multiple profiles is pretty > straightforward (using the -p switch). I use a compile profile for > guix, for example, containing gcc etc. I already found out that creating profiles is easy, which is a nice feature. But I may well need to mix different Guix commits in one and the same profile. Here's an example (a simplified version of the real situation that motivated me to check out Guix): - I need to use Program X that depends on libraries A and B. - The current versions are A-1.1 and B-42.0.1. - X requires "1.0 or later" for A but "41.*" for B, because version 42.* of B is not fully backwards compatible. If there's no Guix commit that has both A and B in the required version range, then the easiest way to get what I need is to use an older Guix commit for installing B than I use for A. In fact, the only other alternative I see is to add a package definition for the old version of B to a later Guix commit. That's likely to be much more difficult. > Note that you can also tar ball a binary package with all its > dependencies (using guix archive) and distribute that. That is > reproducible at the binary level. That may be more useful for end-users. That's what I would use to share environments with collaborators. But I wouldn't download binaries from a stranger, and I don't expect others to have a different attitude. Konrad.