Re: Linux-4.X-rcY patches can't be applied with git?

[Josh Boyer]

On Mon, Oct 24, 2016 at 10:49 PM, Jarod Wilson <jarod@xxxxxxxxxx> wrote:
> On Mon, Oct 24, 2016 at 05:06:42PM -0700, Linus Torvalds wrote:
>> On Mon, Oct 24, 2016 at 4:18 PM, Jarod Wilson <jarod@xxxxxxxxxx> wrote:
>> >
>> > But in that case, what if your patch generation script used a filter to
>> > exclude those binary files? No harm to that target audience, and it would
>> > actually make them behave better for distro builds. Though that might be
>> > counter to the goal of making them disappear entirely. :)
>>
>> Heh, I'd rather people get the warning that "oops, something is
>> incomplete". They can still work with the end result, but at least
>> they got some indication that hey, that patch didn't work wonderfully
>> well...
>>
>> To be honest, I really would like to not do the tar-balls and patches at all.
>>
>> But maybe rather than saying "it's only for legacy 'patch' users", I
>> could just say that it's getting phased out, and say "you have to use
>> 'git apply' to apply them".
>>
>> Then I could just enable "--binary" and "-M", and see what happens.
>
> I like this idea!
>
>> I suspect that these days, git is so ubiquitous that it's ok.
>>
>> And then in a few years, maybe I can just stop doing patches entirely,
>> having proved the point that everybody already has git ;)
>
> Honestly, the only people that don't have access to git to pull down
> kernel sources? People who haven't yet got a kernel up and running, who
> will probably get there via a distro kernel. ;)

Possibly.  And to your earlier idea of generating our own diffs, we do
that for the subset of git snapshot builds we do in Rawhide between
the -rcX releases.  The problem with doing that all the time for
everything is that today the -rcX patches are signed by Linus.  Doing
it ourselves means they aren't.  Fedora/other distros could have the
maintainers sign their generated diffs but it loses some of the
verification chain.

> Side note in favor of tarballs: I know Fedora likes upstream to have
> tarballs, with checksums provided, so that packages can be verified to
> contain a legitimate upstream source tarball, rather than a random tarball
> created by the packager that could have some extraneous bits (possibly
> malicious) added to them. One can certainly examine and validate a
> generated tarball too, but it's a fair bit more work than just "does the
> checksum match?" and not as easily automated.

Right, this and the signing issue I pointed to above.

josh