Re: 02/02: gnu: libical: Add upstream patch to preserve API compatibility.
Hi, On Fri, 7 Feb 2020 at 22:44, Ludovic Courtès wrote: > Marius Bakke skribis: > > I wonder if it's feasible to use Guile-Git to generate the patches > > instead, at the expense of having to download the entire repository > > for the purpose of extracting one or more (substitutable) patches. > > Good question. We could have a lowerable data type that > would (1) clone the repo, and (2) dump the raw (?) commit to #$output. > It’s happening on the build side, like ‘git-fetch’, so it could use Git > directly, which supports shallow clones. I do not know if it makes sense but Git provides now a (experimental) partial download/clone. https://git-scm.com/docs/partial-clone All the best, simon
Re: 02/02: gnu: libical: Add upstream patch to preserve API compatibility.
Hi! Marius Bakke skribis: > Ludovic Courtès writes: > >> Howdy! >> >> guix-comm...@gnu.org skribis: >> >>> + (list (origin >>> + (method url-fetch) >>> + (uri (string-append >>> + "https://github.com/libical/libical/commit/; >>> + >>> "ae394010c889e4c185160da5e81527849f9de350.patch")) >> >> IIRC, those generated patches are not stable, like generated tarballs, >> no? What are the available options? > > I haven't seen GitHub change such generated patch files yet[*], but I do > agree it's "fragile", because they can be difficult to reproduce when > GitHub inevitably disappears, or _do_ change the format. Yeah, I remember Cgit would include its version number in patches, for instance. > I wonder if it's feasible to use Guile-Git to generate the patches > instead, at the expense of having to download the entire repository > for the purpose of extracting one or more (substitutable) patches. Good question. We could have a lowerable data type that would (1) clone the repo, and (2) dump the raw (?) commit to #$output. It’s happening on the build side, like ‘git-fetch’, so it could use Git directly, which supports shallow clones. Sounds like it could work! Ludo’.
Re: 02/02: gnu: libical: Add upstream patch to preserve API compatibility.
Ludovic Courtès writes: > Howdy! > > guix-comm...@gnu.org skribis: > >> + (list (origin >> + (method url-fetch) >> + (uri (string-append >> + "https://github.com/libical/libical/commit/; >> + >> "ae394010c889e4c185160da5e81527849f9de350.patch")) > > IIRC, those generated patches are not stable, like generated tarballs, > no? What are the available options? I haven't seen GitHub change such generated patch files yet[*], but I do agree it's "fragile", because they can be difficult to reproduce when GitHub inevitably disappears, or _do_ change the format. I wonder if it's feasible to use Guile-Git to generate the patches instead, at the expense of having to download the entire repository for the purpose of extracting one or more (substitutable) patches. [*] There was one instance where it had changed, but that was a merge commit(!), which is a pretty extreme case (whoops): https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7670efefe4fb4aca12cb19ea5d89ff37c48e3ea6 signature.asc Description: PGP signature
Re: 02/02: gnu: libical: Add upstream patch to preserve API compatibility.
Howdy! guix-comm...@gnu.org skribis: > + (list (origin > + (method url-fetch) > + (uri (string-append > + "https://github.com/libical/libical/commit/; > + > "ae394010c889e4c185160da5e81527849f9de350.patch")) IIRC, those generated patches are not stable, like generated tarballs, no? What are the available options? Thanks, Ludo’.
