[Top][All Lists]

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

Re: ‘snippet’ in <origin>

From: Ludovic Courtès
Subject: Re: ‘snippet’ in <origin>
Date: Fri, 08 Nov 2013 14:02:20 +0100
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>> address@hidden (Ludovic Courtès) skribis:
>>> +                 ;; See 
>>> <>.
>>> +                 '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
>> 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.

Hmm OK, makes sense.

>> 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?

The rationale for me is that <origin> should remain simple, while the
package’s build system would handle anything non-trivial.  For that
reason, and also because I knew it would avoid a full rebuild, I avoided
full-blown phases.

Now, I think we could replace ‘snippet’ by ‘phases’.  That field would
contain an <origin-phases> object with exactly 4 fields: unpack, patch,
user (default to #f), and repack.

In the LAPACK case, we’d do:

    (uri ...)
    (sha256 ...)
    (phases (origin-phases (inherit %standard-origin-phases)
              (user '(for-each delete-file ...)))))

I think that would address your problem.  The set of phases would be
fixed, though, unlike what ‘gnu-build-system’ does, but I think that’s

How does that sound?

If that’s workable without triggering a full rebuild, I can look at it
by 0.5.  Otherwise that’ll have to wait.

Thanks for your feedback,

reply via email to

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