> I've recently enountered a package which needs "/src" appended to
> WRKSRC, but to which I would like to apply some patches to files outside
> of the build directory (particularly to manual pages that will be
> installed).
> 
> It didn't take me very long to figure out that package patches are
> applied with "patch -d ${WRKSRC}", which of course makes it harder to
> apply patches to files outside of ${WRKSRC}.

> Although there are several work-arounds to this problem, ...

> Of course that's not the only change that's necessary....  every package
> that requires the setting of WRKSRC may need the pathnames in its
> patches updated too, and that's no small number of packages (about
> 340!).  So, this raises the question: Is it better to make the design
> more elegant now while there are only 340 packages to check and fix, or
> is this problem rare enough that it's better to document and employ one
> of the two potential work-arounds only where necessary?

There are, as you have noted, several workarounds to this program,
which seem to work fine, and are a tad less intrusive than modifying
340 other packages.

One rule of thumb that I have used in pkgsrc is that where I start
to use workarounds for anything more than a handful of packages,
then that is when changes should be considered, based upon how much
upheaval in the rest of pkgsrc any of these changes is going to
make. Frankly, your proposed change doesn't score very well.

I'm also not convinced that it's a major problem. WRKSRC is, after
all, the root of the tree in which work will be taking place. And
so, if you are patching files outside WRKSRC, that would imply that
you have WRKSRC set wrongly. Thus, you should either consider adding
a Makefile in the directory above src, which will cd into src and
do all the work, or, alternatively, use patch files which modify
files with pathnames starting ../

Alistair