blob: b901725029444eda89cbb141dd57561a50515314 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
================
=== W[hat]TF ===
================
Gentoo patchsets that have grown too large to keep on the rsync mirrors have
been moved to our git tree. From there, we bundle up all the wee little
patches into a tarball and distribute it via our public mirroring system.
If you want specific info about a patch (like wtf it does or whose great idea
it was to change the code), read the patch! We try to fill out the top of
them with useful info such as what it does, why it's needed, bug reports,
original creators, etc.
=================
=== W[here]TF ===
=================
gitweb: https://gitweb.gentoo.org/proj/toolchain/linux-headers-patches.git/
read-only git tree: https://anongit.gentoo.org/git/proj/toolchain/linux-headers-patches.git
read-write git tree: git+ssh://git@git.gentoo.org/proj/toolchain/linux-headers-patches.git
===============
=== H[ow]TF ===
===============
The patch naming/applying convention might be a little confusing to the Gentoo
outsider, so here's a quick rundown. Patch tarballs are applied in Gentoo via
a helper command called "eapply".
Patches should use -p1.
The epatch command will also use the -E option by default as the `patch` command
can be pretty picky about removing files. We just force the issue. If you
really need to empty out a file but leave it behind, people can use `touch` in
the ebuild.
The patch naming convention is part rigorous and part open ended. By default,
the patch should follow:
#_<arch>_<desc>.patch
The number field is to provide strict numerical ordering and has no limit (well,
except for your IMAGINATION). The <arch> field corresponds to the Gentoo arch
naming convention (so expect to see "amd64" instead of "x86_64"). If you see
"all" (which is how we strongly encourage people to manage things), then the
patch should be applied for all arches, and any arch-specific issues can then
be handled at build time (configure detection or something). The <desc> is a
free form field where people can stick whatever they want.
|
GitWeb
