Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> l...@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’.