[ On Saturday, March 22, 2003 at 22:42:13 (-0800), Jeremy C. Reed wrote: ]
> Subject: Re: hardcoded etc/rc.d in PLISTs instead of RCD_SCRIPTS_EXAMPLEDIR
>
> > > because packages use a lot more than just install(1) to put files in
> > > the right place.
> 
> Exactly. Many files installed via pkgsrc are initially installed with cp,
> mv, tar, pax, cpio, ln, and various custom installers (instead of
> install(1)).

You exaggerate badly.  This is not true of any packages which use
Automake (of which a vast number do), nor even of many which use
Autoconf and/or Imake (of which an even larger number do), or even of
quite a few more which are reasonably portable and were written since
the early days when there was no, or only one, "install" program.

> Nobody has the time to go through all this software to make them have a
> consistent installation method (or tool).

People who are building and testing packages for pkgsrc certainly should
be at least highly aware of whether the software they're working with
uses "install" to copy its files into place or not, even if they're not
prepared to patch it to use "install".

Think about what we're discussing here and its relative importance to
the question at hand (it's related to what's in in the subject header in
case you've focused on the trees too much).

> For the 30+ packages I have made, "make print-PLIST" usually provides a
> good (and sometimes excellent) start.

I've probably done well over twice that many overall and I still find it
a _lot_ faster and much easier (and no doubt just as reliable as I'm
sure I remember finding, more than once, mistakes made by print-PLIST
users) to just cut & paste & edit the "make install" output.  In a few
cases I also need to use "ls" to find the content of some directory when
the make output "hides" the commands used to put those files in place
(usually because of some poorly written loop), but that's rarely any
problem.

Either way we're only talking about one, or a very VERY few, highly
visible file(s) here.

(and if you're updating a package and not very carefully using "sort"
and "diff" or "comm" to examine what's changed in your new PLIST, no
matter how you created it, then you're not being very careful!)

And still for software which does use "install", and for those who would
use "make print-PLIST", use of the METALOG feature would greatly improve
things -- probably even to the extent I'd use "make print-PLIST" myself.

Last, but far from least, "make print-PLIST" already fails to work for
packages which use "archive" tools such as "tar" to install some/all of
their components, as per the comment above the target definition in
mk/bsd.pkg.mk:

# XXX will fail for data files that were copied using tar (e.g. emacs)!


In any case as has already been suggested if print-PLIST were to simply
prefix with "@comment" any files it finds to be new in share/examples/rc.d 
then this whole issue goes right out the window where it came in out of
the blue from.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>