[ On Thursday, February 7, 2002 at 14:43:03 (-0500), Nate Johnston wrote: ]
> Subject: Re: Handling 3rd party rc scripts
>
> This leaves me with just one question: my /usr/pkg is NFS mounted, and
> now I have packages installing files in /etc, which I am not now nor
> ever will I NFS mount, not even a subdirectory.  I have PKG_DBDIR set to
> /usr/pkg/db.  So how do I maintain consistency for all 300 machines that
> centrally mount /usr/pkg?

You've got a second problem too -- if you NFS-mount /usr/pkg then how do
you tailor package configurations for specific hosts?  You still need a
per-machine configuration directory.  It's best to keep it all in /etc
-- one place for everything related to the individual machine.

> As best I can tell, I either need a two-stage rc (the first cut of which
> I posted in a reply to the earlier thread), or this issue will need a
> work-around hack.  I'm sure this scenario has figured into your
> thoughts, and I ask you what comment you have on this scenario.

Personally I've not been quite so ambitious to try sharing /usr/pkg.
I'd much rather simply dedicate a couple hundred megabytes of disk space
on each host and install unique instances of binary packages on each one
-- there are few advantages to having shared filesystems like /usr/pkg
any more, and fewer even still when complications such as this arise.

However if you really must share /usr/pkg then you will have to work out
some way of configuring each package (that needs configuration) on each
host, regardless -- installing rc.d scripts is just part of the
configuration process (even though they are themselves not really
configuration items).  So to this end the initial move in pkgsrc to
install rc.d scripts in ${PREFIX}/share/examples/${PKGBASE} is probably
the best scheme -- then your configuration process has a shared original
to copy from, just as there are shared originals of the template
configuration files already installed into share/examples.

If I'm not mistaken some other existing package management tools have
taken this approach with very good success (i.e. they have a process to
install a package in the shared filesystem, and then another process to
activate it for a given client, and that activation includes making
local copies (perhaps with some default editing too) of configuration
files, startup scripts, etc.).

Note that if pkgsrc would make better use of things like the REQ{IRE}
and INSTALL scripts it would be relatively easy to extend them to
include this additional activation process.  Then you'd do a "pkg_add"
on the file server, and "pkg_install" on each client.  Even DEINSTALL
could be extended to allow for client de-activation without full
de-installation.

-- 
								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>