Proposal: mechanism for local patches

[Garrett Cooper]

On Thu, Dec 4, 2008 at 12:13 AM, G. Paul Ziemba
<pz-freebsd-ports at ziemba.us> wrote:
> amdmi3 at amdmi3.ru (Dmitry Marakasov) writes:
>>> 1. Good that it's at the end of the do-patch target - that way local
>>>    patches can happen after the "official" patches
>
>>Not sure if it's good actually.
>
>>On the one hand, you usually have patches against vanilla sources, and
>>just want to drop them to some dir and have them applied.
>>Also, there's USE_DOS2UNIX that comes before any actual patching, so for
>>ports that use USE_DOS2UNIX you'll have to adapt patches by hand.
>
>>On the other hand, this may cause conflicts with patches from ports,
>
> If the local patches were applied before the official ports patches,
> the official patches could fail, or they could undo some of the
> modifications made by local patches. I think it would be an incorrect
> result.
>
> >From the point of view of the local patches, there is potential for
> variation in the upstream files regardless of whether they are
> modified by official ports patches, so doing local patching first
> doesn't let you avoid tweaking local patches from time to time.
>
>>Updated version here:
>>http://people.freebsd.org/~amdmi3/local-patchdir.patch
>
> It looks good to me. Thanks!

FreeBSD maintained patches can change at any instant a developer makes
a commit to the ports tree, so doing either a vanilla patch or a patch
after a patch will require some level of rework, regardless.

One thing though -- I think that if this item does get supported it
should be noted that while the FreeBSD project supports the patching
functionality, they shouldn't be in charge of the patches. I know most
users / admins would understand this point clearly, but it needs to be
made apparent in the port distfiles, or using some method, that an
individual is using self-patched and maintained sources.

Gentoo Linux uses the concept of portage overlays to deal with this
issue, but I'm not sure if that's the best method to approach this
problem with, as our ports system isn't yet adapted to this level of
thinking, and since we don't have a means of masking port versions
today (mind you -- I'm not really suggesting that this should be done
-- version masking and arch masking is a real maintenance nightmare
for the support groups and we have enough fun dealing with our ports
tree :)..).

My 2 cents,
-Garrett