[ On Saturday, February 9, 2002 at 20:23:59 (-0500), Shannon wrote: ]
> Subject: Re: Summary: Third-party rc.d scripts
>
> What about stuff put in /usr/local or /opt? If we create a package, I
> assume you would think the same rules apply, giving us local_named and
> opt_named.

Note that you cannot, yet, have the same package installed in multiple
locations on the same machine, not even different versions of the same
package since they automatically "conflict" with each other.  As such it
seems obvious that the prefix used to tag an rc.d script name should
have something to do with the package management system, not anything to
do with where it is installed and so "pkg_" is ideal since it matches
the prefix on the pkg_install commands.  Pkgsrc is essentially designed
with the expectation that the setting of LOCALBASE will not change
across time on a given host.  The same applies for binary packages that
might be built for installation on other hosts.  I.e. it's irrelevant
where a package is installed since it'll be the same place as all the
other pacakages.

(not only that but if you used the location then you'd really have to
use _all_ of the location, and so if packages are in /a/b/c/d/e/f then
the prefix would have to be a_b_c_d_e_f_${PKGBASE}!  yuck!  :-))

(You can potentially have multiple target locations with multiple
settings of PKG_DBDIR, but this is most certainly NOT a default
supported scenario!  If it even works managing it properly would require
a great deal of care, and would certainly imply unique settings for
PKG_SYSCONFIDR too!)

(you could also fool pkgsrc with FORCE_PKG_REGISTER=1, but that's
cheating and I'd guess also not officially supported!)

-- 
								Greg A. Woods

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