On Sat, 9 Feb 2002, Greg A. Woods wrote:

> [ On Saturday, February 9, 2002 at 19:06:04 (-0600), Frederick Bruckman wrote: ]
> > Subject: Re: Summary: Third-party rc.d scripts
> >
> > Well, currently, ${PKG_SYSCONFDIR} defaults to ${PREFIX}/etc, so
> > that's a boon for the fellow who wants to share configs between 300
> > machines.
>
> Yes, very well fine and good, except for host-specific config files,
> such as most notably and most importantly some of those for SSH (and
> many other examples can be trotted out for specific uses of any number
> of other packages).  Such files cannot be shared since they are, by
> definition, host-specific.

Of course. [I forgot how to make the toungue-in-cheek thing. :-\ ?]

> There are so many possible factors to this issue that no one answer can
> ever be right for everyone.

My thoughts exactly.

> However in general the first option, if
> it's implemented, is the one that's going to be guaranteed to always
> work for all packages and it may actually be the easier option too
> (depending on how well planned the overall setup procedures are, and how
> static the machines are, what they are used for, etc.).

I assume, by "first option", you're talking about a stand-alone
generic post-install script. You know, "pkg_info -i pkg" displays the
+INSTALL script in the package. Does that mostly do what you're
looking to do? There are probably many commands embedded in the
+CONTENTS files, though, that should properly go in +INSTALL.

> One way or another some procedure must be followed to configure each
> host, even if the clients share the majority of their files on some
> commonly accessed file server.  If a well defined procedure is made
> available in canned form for locally "activating" packages installed on
> a shared file server then it can be invoked as part of the procedure
> used to configure each host.
>
> What's important here is to realise that packages may have host-specific
> configuration files, just as the system itself does.  If NetBSD's pkgsrc
> is to properly and full support the sharing of installed packages then
> some mechanism needs to be invented which manages these files in a
> consistent manner and which can be automated so as to facilitate mass
> configuration of many hosts.

We could probably accomplish a lot of that by not taking so many
liberties with INSTALL vs. PLIST. I really hadn't thought about it
before.

> As has also been pointed out if it is to really be complete such a
> procedure also needs a way to register to the server which packages have
> been "activated" on a given client host.  This way when a package is
> updated any new host-specific files can be added to a given client
> host's local configuration directory; and the server administrator will
> find out if any clients will be affected should a package be deleted,
> etc.

This is getting way too abstract for me. My only experience of mass
installs is where every host or device gets the same image, and then a
simple procedure is followed to configure the differences.

> Alternately perhaps it's best if pkgsrc simply declare that the sharing
> of installed packages is not officially supported, and people who need
> to do such sharing can work out their own local hacks for any of the
> specific pacakges they use which might require host-specific
> configuration.  Hints can be documented for appropriate settings for the
> like of PKG_SYSCONFDIR, and so on, just as we now have hints for setting
> up diskless clients, but no canned procedures.  Perhaps they'll be lucky
> and none of the packages they use will have host-specific configuration
> files.  :-)

I agree, in principle, that such a configuration should be
supportable, but I couldn't pretend to *support* it. Maybe someone
who's actually done it can tell us what they did, and if anything in
pkgsrc got in their way.

It seems like there's finally a consensus brewing on where to install
the rc.d scripts, and I'd like to get on with that. As far as the
sharing ${PREFIX} situation goes, installing scripts directly into
/etc/rc.d shouldn't cause that much of a problem, as long as there are
no conflicts: you just "pax -r -w -pe -v /etc/{rc.d,defaults}/* ..."
to a shared directory periodically or after installing new packages.

Frederick