patchfiles and specifying -p

[Blair Zajac]

On 05/17/2010 08:14 AM, Ryan Schmidt wrote:
> On May 17, 2010, at 05:59, Rainer Müller wrote:
>
>> Whatever syntax we choose, it should probably be generalized to allow
>> any special patch options to be passed. I agree that -p will probably be
>> the most used argument. But it could also be required to ignore
>> whitespace with -l or increase the fuzz factor with -F.
>>
>> Just adding another colon separated parameter looks a bit strange if you
>> have no subdir or tag or just one of them:
>>
>> patchfiles foo.diff:subdir:tag:-p2
>> patchfiles foo.diff::tag:-p2
>> patchfiles foo.diff:subdir::-p2
>> patchfiles foo.diff:::-p2
>>
>> Another option would be to make it a list:
>>
>> patchfiles {foo.diff -p2} bar.diff
>>
>> Other ideas?
>
> Do we really need any changes? I mean we've gotten by so far without them.
>
> If I have a patch that has too much fuzz, I regenerate the patch. If it needs a -p option, I specify it in the patch.pre_args, like the guide says to. If I want to mix this patch with other patches already in the port that use a different -p option, I edit the patches so they all use the same -p option.

I don't want to have to modify patches.  I like taking patches from 
Ubuntu/Debian and the upstream source and drop them into a portfile with 
no modifications.  I shouldn't need to regenerate a patch just to get 
them all to have the same -p value.  RPM spec files don't require this, 
Ubuntu/Debian packages don't.

If we don't want to have a way to specify -p, then we can do what Debian 
does, which is try to apply the patch with -p 0, -p 1 up to -p N until 
it succeeds or fails.  This would be fine with me.

Blair