[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 02/02: gnu: libical: Add upstream patch to preserve API compatibilit
From: |
Ludovic Courtès |
Subject: |
Re: 02/02: gnu: libical: Add upstream patch to preserve API compatibility. |
Date: |
Fri, 07 Feb 2020 22:44:20 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hi!
Marius Bakke <address@hidden> skribis:
> Ludovic Courtès <address@hidden> writes:
>
>> Howdy!
>>
>> address@hidden 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 <git-commit> 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’.