On Thu, 23 May 2002, Julio Merino wrote:

> On Thu, May 23, 2002 at 08:25:52AM -0500, Frederick Bruckman wrote:
> > On Thu, 23 May 2002, Julio Merino wrote:
> >
> > The intention is for "pkg_add" to install and register the scripts to
> > a holding area, then to have the INSTALL script activate them by
> > copying them to "/etc/rc.d/". This can accomodate network mounted
> > /usr, shared "${PREFIX}", and build-only machines that won't ever run
> > the package. The fact that some people can trivially execute some of
> > the scripts directly from the holding area ("${PREFIX}/etc/rc.d")
> > isn't relevant -- it doesn't work in general, and it's not
> > supportable. Your change won't even be able to support separate root
> > and /usr partitions. ${PKG_SYSCONFBASE} doesn't have to be on the root
> > file-system, but the scripts must be.
>
> Well well, apart from the patch, I didn't explained what I wanted properly.
> If I change PKG_SYSCONFBASE to anywhere else, shouldn't default scripts
> get installed there (the ones in the holding area)? So maybe the thing to
> do is to fix packages to install their scripts into ${PKG_SYSCONFBASE}/rc.d
> and then let bsd.pkg.install.mk move them to /etc/rc.d. What I mean is that
> those packages have ${PREFIX}/etc/rc.d into them and the "etc" directory is
> controlled by PKG_SYSCONFBASE?
>
> Is this ok?...

I don't think so. If ${PKG_SYSCONFBASE} equals "/etc", won't the
generated INSTALL script then be copying the rc.d script onto itself?
${PKG_SYSCONFBASE} and friends are for human-editable scripts with
compiled in locations. The rc.d scripts are neither; they're for the
system or administrator, to help manage the package, not for the
package.  You can vary where you put the package's own config files,
at compile time, but that has (or should have) nothing to do with
where you store the rc.d scripts.

Frederick