Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Originally posted by mudelf "Reversed (or previously applied) patch detected! Assume -R? [n]
Apply Anyway? [n]"
'patch' tries to apply a piece of code, but the modifications already seam to be applied. Here are some parts of the manual that explain this a little further.. (because I honestly don't quite know how to explain it)
Quote:
-R or --reverse
Assume that this patch was created with the old and new files swapped. (Yes, I'm afraid that does happen occa-
sionally, human nature being what it is.) patch attempts to swap each hunk around before applying it. Rejects
come out in the swapped format. The -R option does not work with ed diff scripts because there is too little
information to reconstruct the reverse operation.
If the first hunk of a patch fails, patch reverses the hunk to see if it can be applied that way. If it can, you
are asked if you want to have the -R option set. If it can't, the patch continues to be applied normally. (Note:
this method cannot detect a reversed patch if it is a normal diff and if the first command is an append (i.e. it
should have been a delete) since appends always succeed, due to the fact that a null context matches anywhere.
Luckily, most patches add or change lines rather than delete them, so most reversed normal diffs begin with a
delete, which fails, triggering the heuristic.)
Quote:
BUGS
[...]
If you apply a patch you've already applied, patch thinks it is a reversed patch, and offers to un-apply the patch.
This could be construed as a feature.
It looks like you're trying to patch a distro specific kernel with a vanilla patch, this is not a particularly good idea. The kernel you're trying to patch is somewhere in between 2.4.18 and 2.4.19, but the patch you're using applies only to 2.4.18, so you're going to have some troubles, but it is probably still possible to get the patch to merge if you really work at it, but I doubt it's worth it.
If you're looking for the 2.4.19 kernel, you can just grab the full source for 2.4.19 and compile that. Or if you really wanted to, you could get the full source for the vanilla 2.4.18 kernel and then patch it with that patch up to 2.4.19. Ideally, you'd just grab one of the newer stable kernels, such as 2.4.22, and compile that. Unless you've got a specific reason to stick with an older kernel, the newer ones are usually better.
Phew !!! Ok that clarifies LOTS of things --- thanks for answering
I am trying to patch simply so that I can understand the process and be able to do so. This is the same case for recompiling the kernel.
Is it ok to apply a vannila kernel to RedHat? I would of thought it would be but then what happens about patching after that? Once I have 'gone vanilla' ( ;-) ) do I have to stay on that road with my patches untill I recompile again?
If all the flavours of Linux are specific in some way (e.g RedHat, Debian etc.) then what is the point of a vanilla one ... ?
I guess the most sensible course of action is to upgrade using a RedHat Source RPM --- however I wanted to understand and be able to do a source recompile for the purpose of learning.
Is there any information at the source cd-rom about the patches they've applied? (slackware does this for example; by providing their modifications in a patch file)
You could start with an original kernel from www.kernel.org, and apply a few patches yourself.
I still would recommend compiling the 2.4.22 kernel. It has many improvements, new features and drivers.
btw, all kernels up to 2.4.20 have a ptrace exploit, you don't want to give anyone a shell on a box with an unpatched 2.4.20 kernel (but there is a patch for that too)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
(but there is a patch for that too)
