Alistair Crooks wrote:
> And to address the point about apache.sh (which, to me, seems like a
> normal rc.d script, and so should be placed in the files/ directory,
> since rc.d scripts are special, and require extra pkgsrc work behind
> the scenes to place in the rc.d directory).  i.e. there is a specific
> pkgsrc component to those files, which is not relevant to the package
> itself.  I am not suggesting that rc.d scripts should be placed in the
> patches directory.  What I am saying is that files which are part of
> the source, which add configuration for platforms which the author did
> not intend or had no access to, should be placed in patches along with
> all the rest of the patches for that package.  I don't think I'm
> straying from current, agreed and well understood practice there.

... and undocumented ... :(

If there had been some documentation on when to use files/ and when to 
use patches/, maybe we could have saved this discussion. As I'm still a 
newbie (I don't even seem to know the "well understood practice" ;)), 
could you please write a note or two in the components.xml file? You 
have far more experience than I do.

To see how things are actually done, I just grepped for /dev/null in the 
patch-* files and found wip/tendra to be a perfect example. In your 
opinion this package is probably perfectly right regarding the patch-* 
files. To me it looks quite weird. I'd rather have those files in the 
files/ directory. Over there, it's much easier to view or edit a file, 
if you already know the filename. In the patches/ directory you first 
have to grep through all patch files.

> However, as we seem to be labouring the point here, it is far easier
> to feed patches upstream if they are all located in one place. It also
> does not violate the principle of least astonishment when they are
> all gathered in one place.

I understand the reasoning you give here, but I still don't fully agree 
with them. Nevertheless I accept them. I have reverted my change.

Roland