Re: ‘snippet’ in <origin>

[ludo@gnu.org (Ludovic Courtès)]

Mark H Weaver <mhw@netris.org> skribis:

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

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.

OK.

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

  (origin
    (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
fine.

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,
Ludo’.