all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: ‘snippet’ in <origin>
Date: Fri, 08 Nov 2013 01:32:24 -0500	[thread overview]
Message-ID: <87r4ars8sn.fsf@netris.org> (raw)
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")

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> +                 ;; See <http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01383.html>.
>> +                 'configure 'remove-non-free-files
>>
>> It’s a case where ‘guix build -S’ will return the 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 ‘snippet’ field in ‘origin’, which is
>> where the ‘remove-file’ calls would appear, (2) host a freed version
>> under alpha.gnu.org/gnu/guix/mirror.
>
> Commit f9cc897 in master adds a ‘snippet’ field in <origin>, 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 <package>.
>
> 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

  reply	other threads:[~2013-11-08  6:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-23  9:08 LAPACK: tests fail; non-free files Nikita Karetnikov
2013-10-23  9:16 ` Nikita Karetnikov
2013-10-23 11:57 ` Andreas Enge
2013-10-24 19:33   ` Nikita Karetnikov
2013-11-04 19:19   ` [PATCH] gnu: Add LAPACK. (was: LAPACK: tests fail; non-free files) Nikita Karetnikov
2013-11-06 13:10     ` [PATCH] gnu: Add LAPACK Ludovic Courtès
2013-11-07  8:49       ` Nikita Karetnikov
2013-11-07 22:43       ` ‘snippet’ in <origin> Ludovic Courtès
2013-11-08  6:32         ` Mark H Weaver [this message]
2013-11-08 13:02           ` Ludovic Courtès
2013-11-08 15:13             ` Mark H Weaver
2013-11-08 21:15             ` Ludovic Courtès
2013-10-23 22:41 ` [PATCH] gnu: cmake: Bump to 2.8.12 Cyril Roelandt
2013-10-24 19:35   ` Nikita Karetnikov
2013-10-28 23:14   ` Ludovic Courtès
2013-10-29  8:22     ` Andreas Enge
2013-10-29 10:42       ` Ludovic Courtès
2013-10-31 22:42     ` Cyril Roelandt
2013-11-01  8:50       ` Andreas Enge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r4ars8sn.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.