Re: Treating patches as part of ‘origin’

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

ludo@gnu.org (Ludovic Courtès) skribis:

> To address that, I think we should move patch handling from the build
> system to the ‘origin’ objects.  That is, we would write:
>
>   (package
>     ...
>     (source (origin
>               (uri ...)
>               (sha256 ...)      ; hash of the upstream tarball
>               (patches (map search-path (list "foo.patch" ...)))))
>     ...)
>
> As a bonus, this would make patches work regardless of the package’s
> build system; we would get rid get rid of the #:patches arguments to
> ‘gnu-build-system’.
>
> I think the effect of having a non-null ‘patches’ list should be to
> fetch the upstream tarball, apply the patches, and re-pack the tarball.
> That way, patching would be completely transparent to build systems
> (they would always get a tarball, regardless of whether it has been
> patched) and to the user (‘guix build --source’ would always return a
> tarball.)  The only downside is the CPU cost of re-making the tarball,
> which could be annoying when working on a package, but I think it’s
> reasonably low for most packages.

Done in commits ac10e0e and 01eafd3.  The latter triggers a number of
rebuilds, which is unfortunate given that Hydra is currently down for
maintenance/upgrade.  The former changes the Scheme ABI, so make sure to
run ‘make clean && make’!

So the official way to introduce patches is now the form shown above.

There’s still work in that area: in ‘core-updates’, I’ll remove the
‘patch’ phase and #:patches argument from ‘gnu-build-system’ & co., and
update the core packages that still use #:patches.

Comments & bug reports welcome!

Ludo’.