From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: =?utf-8?B?4oCYc25pcHBldOKAmQ==?= in Date: Fri, 08 Nov 2013 01:32:24 -0500 Message-ID: <87r4ars8sn.fsf@netris.org> References: <87ob6gpd5k.fsf@karetnikov.org> <20131023115728.GA17339@debian.eduroam.u-bordeaux.fr> <87iow8km91.fsf_-_@karetnikov.org> <87eh6tk75p.fsf@gnu.org> <87a9hfq1df.fsf_-_@gnu.org> 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]:56781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vefcf-0001y0-DB for guix-devel@gnu.org; Fri, 08 Nov 2013 01:32:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vefca-0007R8-8R for guix-devel@gnu.org; Fri, 08 Nov 2013 01:32:49 -0500 In-Reply-To: <87a9hfq1df.fsf_-_@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Thu, 07 Nov 2013 23:43:24 +0100") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Hi Ludovic, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > ludo@gnu.org (Ludovic Court=C3=A8s) skribis: > >> + ;; See . >> + 'configure 'remove-non-free-files >> >> It=E2=80=99s a case where =E2=80=98guix build -S=E2=80=99 will return th= e source including the >> non-free files, which is clearly not what we want (though I gather that >> the next upstream version of LAPACK will be fixed, right?). >> >> Two things we could do: (1) add a =E2=80=98snippet=E2=80=99 field in =E2= =80=98origin=E2=80=99, which is >> where the =E2=80=98remove-file=E2=80=99 calls would appear, (2) host a f= reed version >> under alpha.gnu.org/gnu/guix/mirror. > > Commit f9cc897 in master adds a =E2=80=98snippet=E2=80=99 field in , which in > this particular case is used like this (commit 6a99575): I think 'snippet' is a bad name for this field. We may want to add additional snippets in the future, such as an unpacking snippet. Therefore, I think the field name should be based on what phase of the process is being inserted or overridden. > Note that things occur in this order: > > 1. The upstream source is unpacked. > > 2. We chdir to the first directory created by that step (normally > there is exactly one.) > > 3. Patches are applied. > > 4. The snippet is run. > > 5. The directory is repacked. > > Of course we get less flexibility by having things hardcoded this way, > but the goal is to keep it much simpler than what is done for . > > Mark: how well would this scheme apply to the mit-krb5 case? I think it wouldn't work at all. The upstream tarball does not contain any directories, so step 2 would fail. The tarball contains only two top-level files: the compressed tarball with the actual source, and the detached signature. More generally, I'm not fond of this inflexible hardcoded approach. I'd prefer to have a set of phases (e.g. unpack, patch, delete, repack) that can be selectively overridden if needed, but with some specialized constructors that make things simple in the common cases. What do you think? Mark