I am attempting to create a rpm of the latest version of a program. The rpm for the previous version contains a number of patch files that make numerous changes various files in the tar.gz as downloaded from the project's website so it will work properly on Linux. The latest version of the program has changed enough stuff that some of the patches now fail to apply. "1 out of 1 hunk FAILED" and so on. Upon comparing the previous version's files to the latest version, I see that the problem is that some of the files that need to be patched have had some stuff moved around a bit, just enough to (apparently) cause patch to fail. By way of experimentation, I manually changed one of the files in the new version to match what the patch says it should be, then created a new patch file from that and it applies and appears to work fine. (I patched the previous version's file, compared the result to the original and made the same change in the new version's file.) This method seems to work fine when the change is only one or two lines, but some of the patches are somewhat more involved than that. It seems to me that there may be an automated way to handle this matter by somehow patching a into b, then compare a and b and make corresponding changes in c. Basically the same process that I just tried manually on a small patch file, without all of the labour and chance of a screw-up that would be involved in manually comparing the old files and rewriting the new file. I have two questions: First, am I going about this the right way? And if so, is there a way to automate the process as described in the previous paragraph? Second, what is the proper convention for handling this in a rpm? The obvious solution seems to be to create new patch files and throw the old ones away, then build the rpm from that. Some of these patches appear to go back several versions, though, so is there a better or more proper way to handle this than just throwing them out and making a whole new set of patches? I have learned a lot more about patch and diff tonight than I ever needed to know before. Very cool stuff, and very useful. -- MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com
From: Frank Cox <theatre at sasktel.net>> ... some of the files that need to be patched have > had some stuff moved around a bit, just enough > to (apparently) cause patch to fail... > ... By way of experimentation, I manually changed one of the files > ... is there a way to automate the process...I am afraid patch is not able to auto-magicaly adapt an old patch to a heavily modified file... Did your manual experimentation involved any "fuzzy logic", pattern recognition or code interpretation...? Maybe check http://en.wikipedia.org/wiki/Patch_(Unix)#Advanced_diffs JD
On Tue, 15 Jun 2010, Frank Cox wrote:> By way of experimentation, I manually changed one of the files in the > new version to match what the patch says it should be, then created a > new patch file from that and it applies and appears to work fine. (I > patched the previous version's file, compared the result to the original > and made the same change in the new version's file.)ugghhh --- doable, but laborious ... ;)> I have two questions: > > First, am I going about this the right way?no -- Usually one unrolls the old tree, applies the patches to the old; and then unrolls the new in a directory 'next to' the first, and diffs from a point above the top of each This produces a new patch set, which may already have some of what the older patches formerly needed to do (or a wholly different approach, when two forks diverge)> And if so, is there a way > to automate the process as described in the previous paragraph?Early automation of a partially understood technology seems like a premature optimization ;)> Second, what is the proper convention for handling this in a rpm? The > obvious solution seems to be to create new patch files and throw the old > ones away, then build the rpm from that. Some of these patches appear > to go back several versions, though, so is there a better or more proper > way to handle this than just throwing them out and making a whole new > set of patches?A serious developer will usually have available a complete copy of the master upstream, and local branches which are used and discarded without a second thought, once the 'fruit' from an approach is 'cherrypicked' [disk space has become inexpensive]; Mere re-packagers can usually get by with less, and simply pluck prior packages containing (in part) tarballs and patches, and diff between two points in time This is to some degree a matter of taste and administrative approach. A big fat batch was used in the old and early kernel and libc days to distribute 'nightly deltas' which one would D/L and apply one after another againast a periodic master tarball. As bandwidth availability has grown, this fell by the wayside, and later distributed version control systems ('VCS') have emerged as the approach favored there The world is moving to building from VCS as well as snap-shotting; for safety's sake, periodically rolling and signing a SRPM or saving a file containing a signed set of checksums for a backup tarball comes to mind as 'good practices' See: http://www.unrealircd.com/ and the prior experience of the Linux kernel folks, as well as at Fedora and Red Hat with the issue of detecting possible hostile substituted checkins> I have learned a lot more about patch and diff tonight than I ever > needed to know before. Very cool stuff, and very useful.I wrote this introduction to let people get an early success doing patching and SRPM building http://www.owlriver.com/tips/patching_srpms/ and it is designed to be approachible -- Russ herrold
Frank Cox wrote:> I am attempting to create a rpm of the latest version of a program. The > rpm for the previous version contains a number of patch files that make > numerous changes various files in the tar.gz as downloaded from the > project's website so it will work properly on Linux. > > The latest version of the program has changed enough stuff that some of > the patches now fail to apply. "1 out of 1 hunk FAILED" and so on. > Upon comparing the previous version's files to the latest version, I see > that the problem is that some of the files that need to be patched have > had some stuff moved around a bit, just enough to (apparently) cause > patch to fail. > > By way of experimentation, I manually changed one of the files in the > new version to match what the patch says it should be, then created a > new patch file from that and it applies and appears to work fine. (I > patched the previous version's file, compared the result to the original > and made the same change in the new version's file.) > > This method seems to work fine when the change is only one or two lines, > but some of the patches are somewhat more involved than that. > > It seems to me that there may be an automated way to handle this matter > by somehow patching a into b, then compare a and b and make > corresponding changes in c. Basically the same process that I just > tried manually on a small patch file, without all of the labour and > chance of a screw-up that would be involved in manually comparing the > old files and rewriting the new file. > > I have two questions: > > First, am I going about this the right way? And if so, is there a way > to automate the process as described in the previous paragraph? > > Second, what is the proper convention for handling this in a rpm? The > obvious solution seems to be to create new patch files and throw the old > ones away, then build the rpm from that. Some of these patches appear > to go back several versions, though, so is there a better or more proper > way to handle this than just throwing them out and making a whole new > set of patches? > > I have learned a lot more about patch and diff tonight than I ever > needed to know before. Very cool stuff, and very useful.You probably can't automate this - but note that many of the patches included in RHEL/CentOS RPMs are to backport fixes from newer versions of the code without bringing in new/different features. So, if you start with newer base code you may not need many/most of the patches at all. -- Les Mikesell lesmikesell at gmail.com