[ On Thursday, February 7, 2002 at 12:46:46 (-0500), Lars Kellogg-Stedman wrote: ]
> Subject: Re: Handling 3rd party rc scripts
>
> It's entirely possible that someone may want to install a more recent build
> of, say, postfix, or ntpd, or whatever, than is available on the stock
> system.  I think it would be a bad idea for this install to tromp on files
> that effectively belong to another package.

It might be bad practice in theory, but given that the system supplied
base files are not monitored by a management system of any kind there is
in fact no conflict in practice.

I've been installing packages with LOCALBASE=/usr ever since 1.3.3, and
indeed installing replacements for system-supplied software using the
pkgsrc system.  This practice does in fact work very very well (at least
for the few packages I use regularly! ;-).  Of course you don't want to
do this to a production system without testing the software first, just
in case it doesn't work -- as I'll show before it's a bit harder to
revert....

Now of course if you install something like named or postfix, etc. in
/usr/pkg, and don't clobber any of the system supplied files except for
the /etc/rc.d script, then you do end up with system software that's no
longer so easy to use (though anyone with shell programming skills could
undoubtably very easily re-instate the functions of the original system
version).

Fortunately in either case (LOCALBASE=/usr or /usr/pkg or whatever) it's
also easy enough to remove the package and re-"install" the base system
over top of itself in order to restore any clobbered system files (just
do it in single user mode for ultimate safety).  This procedure gets a
bit more complex if you've got several packages to untangle, but with
binary packages you can generally just de-install and re-install them
(sometimes without loosing their local configurations, though not all
packages are so well behaved as, say, ssh).

So, either way in practice there's no problem, at least for now, with
clobbering system supplied files, provided that you know how to invoke
the relatively simple undo procedures should you ever wish to revert
what you've done.

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