guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ‘snippet’ in <origin>


From: Mark H Weaver
Subject: Re: ‘snippet’ in <origin>
Date: Fri, 08 Nov 2013 01:32:24 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi Ludovic,

address@hidden (Ludovic Courtès) writes:

> address@hidden (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 via email to

[Prev in Thread] Current Thread [Next in Thread]