[Dev] Re: embarrassing patch question

Tanner Lovelace dev@trilug.org
28 Feb 2002 16:15:29 -0500


--=-4+h4G9p+AiDkScl6ZEZ1
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Whoa!  Calm down.  Take a deep breath.  Feel better?  Okay.

Now, I think I know what's happening here.  The key statement
below is that you said=20

> For what it matters, all three directories have the include/asm=20
> link to include/asm-ppc as they should.

Now, diff and patch are powerful tools, but in reality
they're pretty dumb.  What is happening here is that when
you do the diff, it's comparing the files in the asm
directories and noting that their different.  It's also
comparing the directories in the asm-ppc directories and
noting they're different, but *without realizing they're
the same directory*!!!  Then, patch is making the same
mistake.  You need some way to tell diff not to follow
the link.  Now, the easiest way would be not to link
the directories until after running diff, but let's
assume that that's already done and you'd rather not
go back and unlink them just to have to link them in
the first place.  Instead, what I suggest doing is
telling diff to "exclude" the directory that is linked.
Pick one of the directories (either asm or asm-ppc)
and include it with the "--exclude=3D<name>" parameter.
For example

diff -Naur --exclude=3Dasm linux.orig linux > k2.patch

That will create the patch and only look at one of
the two directories (since they are the same).  Therefore,
when you go patch the new directory, it won't refer
to both asm and asm-ppc.

BTW, I found all of the above in the diff man page.
Don't knock it when it is obviously where you need to
look.

Tanner

On Thu, 2002-02-28 at 15:56, John F Davis wrote:
>=20
>=20
> Hello
>=20
> Thanks for pointing out your man page opinions, but I read it a long time
> ago and many times since.
> Maybe I need to be clear on my question so I won't be given simple answer=
s
> like read the man page.
> I'm asking because the man page is unclear as to how to use diff and patc=
h
> together to get
> a good patch file and patch application method.
>=20
> So one more time with feeling (and more details). I've got two directory
> kernels in the current directory:
> linux-2.4.2_hhl20 (The modified kernel directory) and
> linux-2.4.2_hhl20.orig (The original kernel).
>=20
> So, from the directory I issue the following command:
> diff -Naur linxu-2.4.2_hhl20.orig linux-2.4.2_hhl20 > k2.patch
>=20
> When the command finishes, I do the following commands to test the patch:
> cp -rf linux-2.4.2_hhl20.orig linux-kernel-to-be-patched
> (I'm giving it this weird name so I can be assured the name of the
> directory doesn't matter.)
>=20
> Then without changing the directory, I attempt to patch the directory lik=
e
> so:
> patch -d linux-to-be-patched -p1 < k2.patch
> (Notice I'm doing the -p1 to ignore the leading dir name, and I'm using
> the -d linux-to-be-patched option so it will use my new funky kernel
> directory
> name.)
>=20
> The patch command runs like gangbusters, until the following occurs:
> <leading output is snipped.>
> patching file include/asm/posix_types.h
> patching file include/asm/siginfo.h
> patching file include/asm/unistd.h
> patching file include/asm-ppc/posix_types.h
> Reversed (or previously applied ) patch detected! Assume -R? [n]
>=20
> And here is why that error occurs:
> include/asm is a link to include/asm-ppc. So, when it applies
> the patch to include/asm/posix_types.h it will fail when it does
> include/asm-ppc/posix_types.h since its already been patched.
>=20
> For what it matters, all three directories have the include/asm link to
> include/asm-ppc
> as they should.
>=20
> Lastly, I wasn't trying to make a career out of diff/patch, I just wanted
> to know how to do it
> quickly and correctly.  I figured it was a 5 minute problem and it only
> needed a 5 minute question
> of someone who knew how to do it to answer.
>=20
> J (what the hell is a man page?) D
>=20
>=20
>=20
>=20
>=20
>=20
> Ed Hill <ed@eh3.com>@trilug.org on 02/28/2002 03:09:08 PM
>=20
>=20
>=20
>=20
>=20
> Please respond to dev@trilug.org
>=20
> Sent by:    dev-admin@trilug.org
>=20
>=20
> To:    dev@trilug.org
> cc:
> Subject:    Re: [Dev] Re: embarrassing patch question
>=20
>=20
>=20
>=20
> Hi John,
>=20
> I think the patch man page does a fairly good job of explaining it:
>=20
>        -pnum  or  --strip=3Dnum
>           Strip   the  smallest  prefix  containing  num  leading
>           slashes from each file name found in the patch file.  A
>           sequence  of one or more adjacent slashes is counted as
>           a single slash.  This controls how file names found  in
>           the patch file are treated, in case you keep your files
>           in a different directory than the person who  sent  out
>           the patch.  For example, supposing the file name in the
>           patch file was
>=20
>              /u/howard/src/blurfl/blurfl.c
>=20
>           setting -p0 gives the entire file name unmodified,  -p1
>           gives
>=20
>              u/howard/src/blurfl/blurfl.c
>=20
>           without the leading slash, -p4 gives
>=20
>              blurfl/blurfl.c
>=20
>           and  not  specifying -p at all just gives you blurfl.c.
>           Whatever you end up with is looked for  either  in  the
>           current directory, or the directory specified by the -d
>           option.
>=20
>=20
> So, you specify a level in the -p option that is sufficient to strip
> away enough leading path entries so that it matches the path that fits
> with your current directory setup.  Thus, you never *have* to have a
> single file in the same directory name it was in when you created the
> patch (if that patch is for a single file)!  Extending the above
> example, the pattern is:
>=20
>   -p0   =3D=3D>  /u/howard/src/blurfl/blurfl.c
>   -p1   =3D=3D>   u/howard/src/blurfl/blurfl.c
>   -p2   =3D=3D>     howard/src/blurfl/blurfl.c
>   -p3   =3D=3D>            src/blurfl/blurfl.c
>   -p4   =3D=3D>                blurfl/blurfl.c
>   -p5   =3D=3D>                       blurfl.c
>=20
>=20
> For a patch containing a set of changes to multiple files in a directory
> tree composed of multiple levels of directories, you will want to keep
> the directory names the same up to the root of the tree.  That is, the
> patch should apply cleanly if all the subdirs have the same names but
> the root directory of the tree can have a different name (which you can
> strip away using the appropriate -p[n] setting).
>=20
> hth,
> Ed
>=20
>=20
>=20
> On Thu, 2002-02-28 at 12:46, John F Davis wrote:
> >
> > Hello
> >
> > Thanks for the reply, but my original question still exists.
> >
> > Here is your answer:
> >
> > 2.1 Create the patch
> >     diff -u oldfile newfile > filename.patch
> >  or diff -urN /olddir /newdir > filename.patch
> >  or diff -urN -X excludes /olddir /newdir > filename.patch
> >
> > diff options:
> >  -u  Output (default 2) lines of unified context.
> >  -r  Recursively compare any subdirectories found.
> >  -N  Treat absent files as empty.
> >  -X FILE  Exclude files that match any pattern in FILE.
> >
> > Note: The -u options can be replaced with -c to create a context format
> >       diff
> >       file with a setting of two lines.
> >
> > 2.2 Apply the patch
> >     gzip -cd patch.gz | patch -p0
> >  or bzip2 -dc patch.bz2 | patch -p0
> >  or patch -p0 < filename.patch
> >
> > patch options:
> >  -p NUM  Strip NUM leading components from file names.
> >
> >
> > Here is my original question:
> >
> >
> > > I think this is right.  However, it would be great if someone would
> clear
> > > up the bit
> > > about the target directory.  Does the target directory have to called
> the
> > > same as the
> > > "patched" or "orig" directory?  Is there a way to specify or edit the
> > patch
> > > file so
> > > that the end user can have their own custom directory name.  For
> > instance,
> > > I used foo and foo.orig, but the end user might have directory names
> > > like foo2 or foo.nfs, etc.
> > >
> >
> > Put another way, in your step 2.2, what is the implied directory name
> used
> >  for the patch?  What is the p1 or p0 bit?  Is that supposed to
> > somehow strip the leading direcotry name or something?  When you issue
> that
> >  comand, are you in the parent directory which owns
> > the kernel directory to be patched or are you in the directory to be
> >  patched?
> >
> > eg.:
> >
> > ls /usr/local/
> > foo foo.orig
> >
> > cd foo
> > patch -p0 < patchfile
> >
> > or
> >
> > ls /usr/local
> > foo foo.orig patchfile
> > patch -p0 < patchfile
> >
> >
> >
> > David Filion <filiond@videotron.ca> on 02/28/2002 11:39:42 AM
> >
> >
> >
> >
> >
> > To:    John F Davis/Raleigh/IBM@ibmus
> > cc:    dev@trilug.org, kernelnewbies@nl.linux.org
> > Subject:    Re: embarrassing patch question
> >
> >
> >
> > John F Davis wrote:
> > >
> > > Hello
> > >
> > > Ok.  I've been using patch and I've asked some questions about it on
> IRC,
> > > but I'm still not
> > > sure about how to use it "CORRECTLY" or in the "PRESCRIBED-METHOD".
> So,
> > > please correct me.
> > >
> > > I want to create a patch file to give to my co-workers and instructio=
ns
> > on
> > > how to use it.
> > >
> > > With that said, here is the scenario:
> > >
> > > I have a original directory called foo.orig and a "up-to-date"
> directory
> > > called foo.latest.
> > > So, I created a patch file using this syntax:
> > > diff -Naur foo.orig foo.latest > foo.patch
> > >
> > > Then to apply the patch, I did:
> > > patch -p1 foo < foo.patch
> > > or
> > > patch -p1 foo.orig < foo.patch
> > > I can't remember which one I did.
> > >
> > > I think this is right.  However, it would be great if someone would
> clear
> > > up the bit
> > > about the target directory.  Does the target directory have to called
> the
> > > same as the
> > > "patched" or "orig" directory?  Is there a way to specify or edit the
> > patch
> > > file so
> > > that the end user can have their own custom directory name.  For
> > instance,
> > > I used foo and foo.orig, but the end user might have directory names
> > > like foo2 or foo.nfs, etc.
> > >
> > > JD
> > >
> > > --
> > > Kernelnewbies: Help each other learn about the Linux kernel.
> > > Archive:       http://mail.nl.linux.org/kernelnewbies/
> > > IRC Channel:   irc.openprojects.net / #kernelnewbies
> > > Web Page:      http://www.kernelnewbies.org/
> >
> >
> > I threw together something a while ago when I was in the same
> > situation, I've included it below.  Because we are using Solaris
> > at work, it covers the older and newer versions of diff/patch.
> >
> > HTH
> > David Filion
> >
> > --- Start of doc ---
> >
> > Creating a patch
> >
> > Below is a cheat sheet for creating and applying patch files.  For more
> > details about each command, check the commands manpage, info document o=
r
> > try "command --help".
> >
> >
> > 1.0 Using older versions of diff/patch.
> >  The older diff/patch utilities don't understand the newer unified
> >  format.  Thus, the older conext format must be used. Thus the -c
> >  option that appears.
> >
> > 1.1 Create the patch
> >  diff -c -b -r /original /new > filename.patch
> >
> > diff options:
> >  -c  Produces a listing of differences with three lines of context.
> >  -b  Ignores trailing blanks (spaces and tabs) and treats other strings
> >      of blanks as equivalent.
> >  -r  Applies diff recursively to common subdirectories encountered.
> >
> > 1.2 Apply the patch
> >  patch -c -l -p1 -d /original < filename.patch
> >
> > patch options:
> >  -c  Interpret the patch file as a context difference (the output of
> >      the command diff when the -c or -C options are specified).
> >  -l  Cause any sequence of blank characters in the difference script
> >      to match any sequence of blank characters in the input file.
> >      Other characters will be matched exactly.
> >    -d  Change the current directory  to  dir  before processing.
> >  -p NUM  Strip NUM leading components from file names.
> >
> > 2.0 Using newer/GNU diff and patch utilities.
> >  Unlike their older counterparts, the newer/GNU versions of diff
> >  understand the unified format of patch file.  This is the format used
> >  by the Linux kernel developers.
> >
> > 2.1 Create the patch
> >     diff -u oldfile newfile > filename.patch
> >  or diff -urN /olddir /newdir > filename.patch
> >  or diff -urN -X excludes /olddir /newdir > filename.patch
> >
> > diff options:
> >  -u  Output (default 2) lines of unified context.
> >  -r  Recursively compare any subdirectories found.
> >  -N  Treat absent files as empty.
> >  -X FILE  Exclude files that match any pattern in FILE.
> >
> > Note: The -u options can be replaced with -c to create a context format
> >       diff
> >       file with a setting of two lines.
> >
> > 2.2 Apply the patch
> >     gzip -cd patch.gz | patch -p0
> >  or bzip2 -dc patch.bz2 | patch -p0
> >  or patch -p0 < filename.patch
> >
> > patch options:
> >  -p NUM  Strip NUM leading components from file names.
> >
> > 3.0 Creating a patch using CVS.
> >  A patch is created in CVS using the rdiff cvs command.
> >
> > 3.1 Create the patch.
> >
> >  o Create a context (default) format diff of release tags rel1 and
> >    rel2 for module.
> >  cvs rdiff -r rel1 -r rel2 module
> >
> >  o Create a unidiff format diff of release tags rel1 and rel2
> >  for module.
> >  cvs rdiff -u -r rel1 -r rel2 module
> >
> > cvs rdiff options:
> >  -r tag  Use revision <tag>
> >  -u  Use the unidiff format.
> >  -c  Use the context format (default).
> >
> >
> > Copyright (c) David Filion (filiond@videotron.ca)
> > Created 2001/09/12.
> >
> >
> > _______________________________________________
> > Dev mailing list
> > Dev@trilug.org
> > http://www.trilug.org/mailman/listinfo/dev
> >
> --
> Edward H. Hill III, PhD
> Post-Doctoral Researcher   |  Email:       ed@eh3.com, ehill@mines.edu
> Division of ESE            |  URL:         http://www.eh3.com
> Colorado School of Mines   |  Phone:       303-273-3483
> Golden, CO  80401          |  Fax:         303-273-3311
> Key fingerprint =3D 5BDE 4DA1 66BE 4F7B BC17  3A0C 932B 7266 1E76 F123
> _______________________________________________
> Dev mailing list
> Dev@trilug.org
> http://www.trilug.org/mailman/listinfo/dev
>=20
>=20
> _______________________________________________
> Dev mailing list
> Dev@trilug.org
> http://www.trilug.org/mailman/listinfo/dev
--=20
Tanner Lovelace | lovelace@wayfarer.org | http://wtl.wayfarer.org/
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
GPG Fingerprint =3D A66C 8660 924F 5F8C 71DA  BDD0 CE09 4F8E DE76 39D4
GPG Key can be found at http://wtl.wayfarer.org/lovelace.gpg.asc
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
 Those who are willing to sacrifice essential liberties for a little=20
 order, will lose both and deserve neither.  --  Benjamin Franklin=20

 History teaches that grave threats to liberty often come in times
 of urgency, when constitutional rights seem too extravagant to=20
 endure.  --  Justice Thurgood Marshall, 1989=20

--=-4+h4G9p+AiDkScl6ZEZ1
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA8fp3xzglPjt52OdQRAiT6AKCJaykZloLJnPccaL+JFOrmi5DKZACgoLGa
LIYYzGNjxWp+azeX0ZSsWAU=
=kusF
-----END PGP SIGNATURE-----

--=-4+h4G9p+AiDkScl6ZEZ1--