l...@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’.