simple question about patches

simple question about patches

[davidge]

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?

thanks


David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: simple question about patches

[Rich Baum]

On Saturday 03 March 2001 12:18 pm, davidge@jazzfree.com wrote:
> 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?
>
> thanks
>
>
> David Gómez
>
> "The question of whether computers can think is just like the question of
>  whether submarines can swim." -- Edsger W. Dijkstra
>
>

They're applied against the last release.  To remove the old patch run the 
same command you used to patch the kernel only add a -R after the patch 
command.

Re: simple question about patches

[Albert D. Cahalan]

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.

Re: simple question about patches

[Alan Cox]

> Long ago, pre* and ac* patches were rare. Patches went from one

Umm wrong. -ac patches for 2.2 regularly did one a day

> line-by-line before the next one came out. Patches always applied
> easily with the (pre-POSIX?) patch command. Version numbers made

patch is Larry Wall

> 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)

Of course people with at least one functioning braincell read the differences
between the two patches, or pick up the patch between the two (handily
maintained on www.bzimage.org for the Linux 2.4ac series)

> 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

You must be using a faulty version fo patch

> 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.

You need at least patch 2.5 for anything. And since patch 2.5 has been out
for rather a few years now this is all ancient ancient history (and was never
relevant in the real world anyway)

Alan

Re: simple question about patches

[Alexander Viro]

[cc trimmed]

On Sat, 3 Mar 2001, Alan Cox wrote:

> > Long ago, pre* and ac* patches were rare. Patches went from one
> 
> Umm wrong. -ac patches for 2.2 regularly did one a day
> 
> > line-by-line before the next one came out. Patches always applied
> > easily with the (pre-POSIX?) patch command. Version numbers made
> 
> patch is Larry Wall
> 
> > 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)
> 
> Of course people with at least one functioning braincell read the differences
> between the two patches, or pick up the patch between the two (handily
> maintained on www.bzimage.org for the Linux 2.4ac series)

... or do something along the lines
cp -rl S2 S2-ac10
bzip2 -d <patch-2.4.2-ac10.bz2 | (cd S2-ac10 && patch -p1 -E)
diff -urN S2-ac{9,10} | tee delta-9-10 | less
							Cheers,
								Al

Re: simple question about patches

[David Weinehall]

On Sat, Mar 03, 2001 at 02:14:18PM -0500, Albert D. Cahalan wrote:
> 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.

[long rant about patch snipped]

Get a clue, Albert.

I've followed the kernel-tree since v2.0.30 or so (no, I'm not
one of those that began hacking with the 0.01-kernels), and almost
every pre-patch, test-patch and ac-patch ever released. I've even
followed some of the other private trees, such as the aa-patches,
Solar Designer's ow-patches and a few others. I've so far experienced
NO problems whatsoever.

Due to the fact that I tend to do quite some bug-testing inside my
tree, I start afresh from a tarball every 10 to 20 major releases
(sometimes more often), which could be regarded as cheating, of course.

But just to give you a helping hand, here's a small primer.

Applying a patch:

cd linux 		# name of kernel-tree

# If you have an unzipped patch
cat ../patches/patch-name | patch -p1 --dry-run

# If everything goes fine
cat ../patches/patch-name | patch -p1


# If you have a gzipped patch
zcat ../patches/patch-name.gz | patch -p1 --dry-run

# If everything goes fine
zcat ../patches/patch-name.gz | patch -p1


# If you have a bz2zipped patch
bzcat ../patches/patch-name.bz2 | patch -p1 --dry-run

# If everything goes fine
bzcat ../patches/patch-name.bz2 | patch -p1


This goes both for applying pre-patches, ac-patches and normal,
version-to-version patches.

Before applying a patch, make sure that you've unapplied
all pre-patches, ac-patches etc.

This is done using the same syntax, but with a -R tacked onto it.


When creating a patch from two kernel-trees, use

diff -u --recursive --new-file linux-old linux-new > [name-of-patch]

or, for single files simply

diff -u old-file [new-file with full path] > [name-of-patch]


Some of this might not be fully correct, but most of it should be.


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </