On Sun, Dec 04, 2005 at 10:22:46AM +0100, Roland Illig wrote:
> Alistair Crooks wrote:
> >On Fri, Dec 02, 2005 at 04:28:21PM +0100, Roland Illig wrote:
> >
> >>Alistair Crooks wrote:
> >>
> >>>On Fri, Dec 02, 2005 at 01:52:31PM +0000, Roland Illig wrote:
> >>>
> >>>
> >>>>Module Name:	pkgsrc
> >>>>Committed By:	rillig
> >>>>Date:		Fri Dec  2 13:52:31 UTC 2005
> >>>>
> >>>>Modified Files:
> >>>>	pkgsrc/doc/guide/files: components.xml
> >>>>
> >>>>Log Message:
> >>>>Don't encourage users to abuse the patch framework for installing
> >>>>pkgsrc-specific files into ${WRKSRC}. I've lately seen too many patches
> >>>>against /dev/null that contain RCS Ids.
> >>>
> >>>
> >>>I don't understand what you're trying to achieve with this artificial
> >>>restriction.  I would much rather have all pkgsrc changes to a package
> >>>be done using the patch stage and framework.  It is much easier, for a
> >>>number of reasons.
> >>
> >>- Files in the files/ directory can be edited more easily.
> >
> >
> >That is neither here nor there.  If you want to make a change to a
> >file in the package, it should be done as part of the ${WRKSRC}
> >expansion of the source.  That gives the whole context, not just a
> >single part of it.
> 
> I worry about misunderstanding you completely. Did you just say that, 
> for example, www/apache/files/apache.sh should rather be 
> www/apache/patches/patch-ap?

I worry that you're missing the point. Setting pkgsrc strategy because
you saw an RCS Id in a patch against /dev/null (and I'm still trying
to follow the reasoning process in that one) is a bit of a stretch.

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.

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.

Now if you are really misunderstanding me completely, and want to
modify the strategy in pkgsrc so that we have modifications to the
package's source all over the place, on a whim because you saw a
number of RCS Ids in some files, then I'm worried.  So let's discuss
it rationally before setting that strategy.

> >>- Patches against /dev/null are larger than plain files.
> >
> >I do not think that pkgsrc strategy should be decided on the tiny
> >amount of extra overhead used by patch(1).
> 
> I am not concerned on overhead. The thing that I'm interested in is 
> mostly usability and cleanliness.

I'm sorry - I took "patches against /dev/null are larger than plain
files" to be a concern about overhead. Please explain.
 
> >In addition, files in the files/ subdirectory need to be copied to
> >${WRKSRC} in a separate target in the Makefile.  This adds to the
> >Makefile's contents.
> 
> Instead of the various ad-hoc tries to copy the files from ${FILESDIR} 
> to ${WRKSRC} or ${WRKDIR}, we could have some variables that do that 
> task consistently for all packages. But that's another issue.
> 
> >>- RCS Ids in patch files always have patch-?? as filename, not the name 
> >>under which the file is installed in ${WRKSRC}.
> >
> >+ Expanded RCS Ids in ${WRKSRC} are not meaningful
> 
> Not even if they get installed later into ${PREFIX}? See the apache.sh 
> example above.

Once again - no-one is advocating that rc.d scripts are placed in patches.

Regards,
Alistair