[ On Thursday, January 27, 2005 at 09:05:58 (-0800), Jeremy C. Reed wrote: ]
> Subject: rc.d PLIST auto-registration (was Re: Desktop files)
>
> On Thu, 27 Jan 2005, Julio M. Merino Vidal wrote:
> 
> > It'd be more or less the same, but if we go the .mk route, I don't plan
> > to automatically add entries in the PLIST in ANY WAY.  It's nonsense;
> > they will always be installed in the same place and with the same name.
> > (On a not-so-unrelated note, rc.d installation should be changed to not
> > generate plist entries automatically, but that's another issue.)
> 
> Removing it is fine with me too.

It's not fine with me, for what it's worth.  For several reasons:

RCD_SCRIPTS_EXAMPLEDIR is still a user-settable option, despite not
being documented as such.  I.e. the scripts are _NOT_ always installed
in the same place....

> Also, should we rename RCD_SCRIPTS_EXAMPLEDIR to _RCD_SCRIPTS_EXAMPLEDIR
> or something to imply that it should not be changed? Or we could just
> hard-code the path itself.

Yes, if you would hard-code the pathname and completely remove the
RCD_SCRIPTS_EXAMPLEDIR variable then this reason would go away.  The
string is not reused so many times that putting it in a macro is worth
the extra overhead, especially since the goal is to always leave it
exactly the same as it is now.


However other files that are mucked about with by the pkgsrc
infrastructure in some way or another are still registered automatically
in the PLIST.  Are you going to propose getting rid of all that
automation as well and force all PLIST sources to be entirely manually
maintained again?  I think that would be a _major_ step backwards.

I think anything and everything that's internally derived and/or managed
by the pkgsrc infrastructure and then installed as part of a package
should always be automatically registered in the PLIST.  Requiring all
the manual dual maintenance is a headache and it is error prone.  The
only things that should have to be manually registered in a PLIST source
file are things that are installed by the third party build code, and I
have a very promising idea of how to get rid of all those too, at least
in a very large percentage of packages.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>