> Alan> The patch is fine. You need to get a non prehistoric version of
> Alan> the patch program (eg patch v2.5)
>
> Alan> [and before Orc gets going, yes you can build patch v2.5 with
> Alan> libc4]
>
> Now it would of course be nice if patch v2.5 didn't have a totally
> fucked up behavior and changed the behavior of command line
> parameters.
I have to admit that I think the POSIX patch behaviour is less than
optimal, and the first time I saw it I went "oh, crap, who came up with
this idea?"
However, I've become less hateful of it. The new behaviour is exactly
the one you'd want if everything goes right. It just silently does the
right thing for people who use patch without ever getting patch errors
or anything like that.
The new behaviour is fairly horrible if something goes wrong, though: it
leaves the ".orig" file only for the files that had trouble, not the
files that were successfully patched without warnings. That makes it
harder to "revert" a patch that had partial problems. It's still
possible, but it's definitely less user-friendly for that case.
Oh, well. The best behaviour would probably be to always do the backup
files, and then if everything patches cleanly you remove the files at
the very end - but if there is any problem what-so-ever you'd leave all
backup files alone, even for files that were successfully patched.
This is one of the things that source control makes a non-issue, of
course, so in that sense the new behaviour is more source-control-
oriented.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/