Messages in this thread | | | From | Josh Boyer <> | Date | Tue, 25 Oct 2016 07:36:00 -0400 | Subject | Re: Linux-4.X-rcY patches can't be applied with git? |
| |
On Mon, Oct 24, 2016 at 10:49 PM, Jarod Wilson <jarod@redhat.com> 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@redhat.com> 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
| |