Frank Cox wrote, On 06/15/2010 11:51 AM: > On Tue, 2010-06-15 at 02:44 -0700, John Doe wrote: >> I am afraid patch is not able to auto-magicaly adapt an old patch to a >> heavily modified file... > > That's what I was afraid of. I was hoping, however, that there might be > some way to verify that everything in the patch has now been done in the > new version. My best idea on that score is to inspect the contents of > the old diff and the new diff to make sure that they are the same length > and refer to the same stuff. > > I guess I'll just have to bite the bullet and rewrite some parts of this > thing manually to match the old patch files. My major concern is that > I'll get lost in the woods and miss something; hopefully comparing the > old patch files to a new diff will allow me to check that. > Frank, Some questions that you should probably think about for yourself, and might help those of us on the list help some more. Where did the original SRPM come from? What was it of/for? Does the original source repository/group exist anymore? ... someone else may have already been here with the product you are looking at. Does the person who is building the new SRPM understand _why_ the old patches were created, i.e., what did it fix? Does the person who is building the new SRPM understand in each patch case that either _what_ the patch 'fixed' has not been fixed in the upstream, or was fixed but not in the same way, i.e., contact upstream and ask if the reasons for the patches has gone away so you don't need to patch for it anymore? Would the upstream be interested in integrating the patches, or similar functionality changes, for you? Would the upstream be interested in integrating the spec file for you? -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter