[65227] trunk/dports/sysutils/moreutils
Ryan Schmidt
ryandesign at macports.org
Wed Mar 24 11:06:20 PDT 2010
On Mar 24, 2010, at 02:47, Emmanuel Hainry wrote:
> Citando ryandesign at macports.org :
>> Revision: 65227
>> http://trac.macports.org/changeset/65227
>> Author: ryandesign at macports.org
>> Date: 2010-03-23 21:10:34 -0700 (Tue, 23 Mar 2010)
>> Log Message:
>> -----------
>> moreutils: use a patchfile instead of reinplaces which can break in unpredictable ways in future updates; fixes doc variant (see #24174)
>>
>
> My change from a patchfile to a set of reinplaces was indeed to
> prevent rewriting the patchfile at each update: the patchfile breaks
> very predictably almost each time I do an update.
> Granted my reinplaces were quite rough (and not enough tested), but
> rewriting reinplaces is easier than rewriting patchfiles. Don't we
> have a middle way?
Patchfiles have the advantage of providing context and notification when things weren't patched in the intended way. It took me quite awhile to figure out first that the reinplace was causing the Makefile problems, and then to figure out what it had been your intention for the reinplace to do. Now that it's a patchfile, it's much clearer to anyone who looks at it what is being changed, and it's IMHO much easier to update, should the patch fail in the future, first because the patch will fail to apply and provide notification of that fact, second because the context in the patchfile shows what was being changed before, providing a clue to the person now doing the updating about what now needs to be changed.
Reinplace is great for inserting variables (like ${prefix}) into files, and perhaps in cases where a certain static replacement needs to be made dozens or more times, which might make a patchfile very large. But to me it doesn't seem the ideal way to handle basic patches.
If you want to change it back, you can; it's your port. But I think doing so is going to cause trouble again down the road.
More information about the macports-dev
mailing list