[ On Saturday, February 9, 2002 at 21:02:29 (-0600), Frederick Bruckman wrote: ]
> Subject: Re: Summary: Third-party rc.d scripts
>
> I assume, by "first option", you're talking about a stand-alone
> generic post-install script.

yes.

> You know, "pkg_info -i pkg" displays the
> +INSTALL script in the package. Does that mostly do what you're
> looking to do?

I was thinking more along the lines of adding another "state" keyword to
be passed as the parameter to +REQUIRE, +INSTALL and +DEINSTALL scripts
along with of the current set of PRE-INSTALL, POST-INSTALL, DEINSTALL,
and POST-DEINSTALL state keywords currently passed to those scripts by
pkg_install and pkg_delete.  A new pair of pkg_install binaries
(pkg_activate and pkg_deactivate?) would be provided as a wrappers to
pull the appropriate script from the database and invoke it with the new
keyword and the appropriate environment.

Alternately the packing list format could be extended to explicitly
handle configuration file templates and rc.d scripts, eliminating the
need for more arbitrary handling in the +INSTALL and +DEINSTALL scripts,
and thus eliminating the need for pkgsrc maintainers to write and
maintain such scripts when they are not already needed for other
reasons.  For example a '@conffile' tag could specify a configuration
file template and its destination pathname, and '@rc_script' could
identify an rc.d script template file which would be installed in
/etc/rc.d (or perhaps in /etc/init.d on SunOS, etc. with hard links to
the default /etc/rc?.d/?NNN* places identified by magic keyword comments
embedded in the script or some such similar nonsense -- which is why the
destination is explicitly not mentioned in the packing list).  Both
template files would also be listed as ordinary files to be installed
and registered in some place like share/examples/${PKGBASE}.  In each
case any existing config files and rc.d scripts would not be overwritten
(maybe even triggering an error for rc.d scripts, and at least a warning
message), and they would only be removed upon pkg_delete (or
pkg_deactivate) if they have remained identical to the templates.  For
example (borrowing the % expansions of @exec and exending PLIST_SUBST a
bit):

	share/examples/foopkg/pkg_foopkg
	@rc_script %F
	share/examples/foopkg/foopkg.conf
	@conffile %F ${PKG_SYSCONFDIR}/%f


I don't know which of these I like best.  They both have advantages,
though I think the latter is clearly easier on pkgsrc maintainers, and
while its obvious limitations are, well, quite limiting and restrictive
in some ways, this may make it easier to always use it correctly.  The
latter, at least the way I explain it above, also centralizes some of
the portability issues of rc.d scripts in the pkg_install binaries
instead of requiring every +INSTALL and +DEINSTALL script to re-invent
solutions.

> There are probably many commands embedded in the
> +CONTENTS files, though, that should properly go in +INSTALL.

You can say that again!  :-)

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

Unfortunately the trend over recent months seems to be more along the
lines of getting rid of INSTALL/DEINSTALL scripts (and of course the
REQ{UIRE} scripts have never been properly exploited).  Personally I'd
be much happier with getting rid of @exec and @unexec completely from
the packing list since those actions can always be done equally well in
the separate scripts, where their purpose is much better defined and
their intent more explicit, and of course where they can be separated
more easily and more explicitly into the different "states" or "phases".
Any multi-statement sript can also look a heck of a lot better when
formatted nicely in a separate file!  ;-)

In any case both of the schemes I describe above will at least hopefully
lead pkgsrc maintainers to think more about the purpose of files
installed as part of a package and to hopefully better identify which
might be host specific and thus require custom handling, not only for
shared installations but also for cleaner upgrades of binary packages
(something much closer to my own current goals! ;-).

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

I have some experience designing what I think have been successful
systems to manage large numbers of clients with primarily shared
filesystems.  There's also a reasonably large body of literature
available describing the various issues and some of the solutions that
have been applied in the past, and the practical experience implementors
and users have had with those solutions.  In this discussion I've been
trying to adapt my past experience, and what I know of that literature,
to the facilities of our NetBSD pkg_install tools.

In your more recent reply to Tracy you've touched on a couple of other
important side issues, at least one of which requires the manager of a
shared installation to do a certain amount of planning so that the
necessary consistency can be maintained across the clients.

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

I would rather see the rc.d scripts installed into, and registered in,
${PREFIX}/share/examples/${PKGBASE} and then copied into /etc/rc.d
either by the "+INSTALL POST-INSTALL" invocation or with the @rc_script
mechanism I describe above (in much the same way some better packages
already handle their other configuration file templates).  The
pkg_delete action could then trigger the removal of any copy in
/etc/rc.d either with the "+DEINSTALL DEINSTALL" action or with the
@rc_script mechanism I describe above (provided it has remained the same
as the the original template in share/examples).  This would make
extending the system to support an additional local client configuration
procedure much easier (this would have to be done in that event anyway).
Starting with this plan now even makes manual handling of local client
configuration doable (though certainly tedious for any significantly
large number of clients :-) since all the necessary files will be
directly available in their original template form in the shared
filesystem.

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