[120684] trunk/dports/devel/srecord/Portfile

[Ryan Schmidt]

On Jun 9, 2014, at 10:37 AM, David Strubbe wrote:

> Why is using a patchfile instead of reinplace preferable?

If reinplace fails, it is silent, replacing nothing, and proceeds to the next command. This is https://trac.macports.org/ticket/15514

So although the reinplace may do what you want today, if you later update the port to a new version, and upstream has meanwhile changed the code you were reinplacing, you may never realize that your reinplace is no longer doing what you wanted.

At best, i.e. in the case that upstream has fixed whatever problem you were fixing, you now have unnecessary statements in the portfile. At worst, upstream has only rearranged code, and the problem still exists, but now reinplace is not fixing it, thereby reintroducing whatever bug you were fixing. Or it could happen that reinplace is now changing lines you did not mean for it to change, thereby introducing new bugs.

A patchfile fixes these problems by providing failure notification when the change could not be applied.

Furthermore, a patchfile provides context: usually three lines before and after the change, and the old and new line. Anyone can see at a glance by reading the patchfile what is being changed. The author can also add comments to the patchfile, explaining why this change is being made. This context can help someone update the patch later, if the patch ever starts failing to apply.

reinplace is good for inserting MacPorts variables into files. In that case, usually we first patch to insert a placeholder string, then use reinplace to replace that placeholder with the actual value.