[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ‘snippet’ in <origin>
Re: ‘snippet’ in <origin>
Fri, 08 Nov 2013 14:02:20 +0100
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 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.
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
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:
(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,