60 lines
2.7 KiB
Plaintext
60 lines
2.7 KiB
Plaintext
|
================
|
||
|
|
=== W[hat]TF ===
|
||
|
|
================
|
||
|
|
|
||
|
|
Gentoo patchsets that have grown too large to keep on the rsync mirrors have
|
||
|
|
been moved to our cvs tree. From there, we bundle up all the whee 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... For simple patches, we reserve the right to assume
|
||
|
|
your IQ is greater than absolute 0 and figure out what it does w/out an
|
||
|
|
explanation. If, by some miracle of science, it falls below the absolute 0
|
||
|
|
mark, you should help mankind by finding some scientists and letting them
|
||
|
|
probe you with their ... erm ... probes.
|
||
|
|
|
||
|
|
=================
|
||
|
|
=== W[here]TF ===
|
||
|
|
=================
|
||
|
|
|
||
|
|
For those with CVS access, you want the 'src/patchsets' dir inside of the
|
||
|
|
'gentoo' cvs module.
|
||
|
|
|
||
|
|
For those w/out CVS access, this URL should help you:
|
||
|
|
http://sources.gentoo.org/gentoo/src/patchsets/
|
||
|
|
(you can also find anon cvs access there too)
|
||
|
|
|
||
|
|
It should be pretty easy to find your way around, you're a big boy after all.
|
||
|
|
|
||
|
|
===============
|
||
|
|
=== 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 "epatch". This command is pretty forgiving when it
|
||
|
|
comes to applying patches.
|
||
|
|
|
||
|
|
For example, it will autodetect the required -p# by starting at 0 and counting
|
||
|
|
up until things apply. So do not expect a patch series to all be at the same -p
|
||
|
|
level even if they all apply from the same source directory. Typically however,
|
||
|
|
people will use -p0 or -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.
|