David G\363mez writes:
> Hi, i've got a newbie question about patches:
> Are the pre* patches ( and i guess also the ac* ones) applied against the
> last release of the kernel or against the previous patch? I mean, when
> 2.4.3pre2 will come out, i need to get also the pre1 patch?
Really, I wouldn't bother anymore.
[stuff for patch creators below -- please read]
Long ago, pre* and ac* patches were rare. Patches went from one
kernel version to the next. You could hope to read a whole patch
line-by-line before the next one came out. Patches always applied
easily with the (pre-POSIX?) patch command. Version numbers made
perfect sense, starting with the 1.0 release. Modems were 14.4 kB/s.
Now you need to back out patches sometimes. New kernel versions
are rare enough that you might as well grab a tarball as needed.
Pre-patches go like this:
200 kB (great: read the patch)
200 kB + 200 kB of old stuff you already read (ugh, read 1/2 of it)
200 kB + 400 kB of old stuff you already read (too boring)
...
200 kB + 1.2 MB of old stuff you already read (forget it!)
Then comes the 1.4 MB patch and, well, that is just too big to read.
So you just want to apply a patch. Well, good luck. The patch command
has changed over the years. It has some ugly heuristics it uses to
find the most destructive way to misinterpret your command. Typically
it will patch a few files correctly (to ensure a half-way applied mess)
before deciding to create new files in a directory above or below the
one you want. (this is Red Hat though... they broke "sort" and "ps"
as well, so maybe "patch" still works like it used to on Slackware)
With bzip2 compression and a crummy old 33 kB/s modem, downloading a
whole new kernel isn't too horrid. With today's jumbo patches you
don't save much by getting them, and they are a pain to use anyway.
BTW, if anyone wants to make a reliable patch, read the man page!
Get the old and new directory names to be the same length, so that
POSIX and non-POSIX patch commands are more likely to behave the same.
Something like this: "diff -Naur old new" where "old" and "new" are
the actual directory names. Kernel version numbers make nice names
if you pad them out to the same length: "2.4.09" and "2.4.10".
I'll end with a quote from the man page. Read it if you make patches!
Gee, looks like Linux being used as an example of what NOT to do.
----------------
If the recipient is supposed to use the -pN option, do not
send output that looks like this:
diff -Naur v2.0.29/prog/README prog/README
--- v2.0.29/prog/README Mon Mar 10 15:13:12 1997
+++ prog/README Mon Mar 17 14:58:22 1997
because the two file names have different numbers of
slashes, and different versions of patch interpret the
file names differently. To avoid confusion, send output
that looks like this instead:
diff -Naur v2.0.29/prog/README v2.0.30/prog/README
--- v2.0.29/prog/README Mon Mar 10 15:13:12 1997
+++ v2.0.30/prog/README Mon Mar 17 14:58:22 1997
Avoid sending patches that compare backup file names like
README.orig, since this might confuse patch into patching
a backup file instead of the real file. Instead, send
patches that compare the same base file names in different
directories, e.g. old/README and new/README.
--------------------
Please drop individual humans from the Cc: list if you respond.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
