[ On Tuesday, June 25, 2002 at 19:45:05 (-0600), Rick Kelly wrote: ]
> Subject: Re: rc.local and rcorder(8)
>
> And I replied that you still have to edit rc.conf as /usr/local/isn't mounted,
> normally, when /etc/rc.d contents is run.

Yeah, but that's a different issue totally un-related to /etc/rc.d/local
and /etc/rc.local.  Your second reply to Luke does contain the proper
fix for that issue.  If you put a critical system daemon on /usr/local,
and that's a separate filesystem, and you don't tell the system about
this change of plan then obviously things aren't going to work as
planned, no matter what kind of system you've got for figuring out the
order of dependencies for the system startup procedures.  Would you
rather manually renumber all the links in /etc/rc3.d to get things to
work right?  Would you rather manually shuffle bits of code around in
some massive old-style /etc/rc script?  Do you really expect the average
user to be able to do either?  I rather like 'rcorder' myself.  I think
if we had a very simple how-to about the rc.subr API in an obvious
manual page (maybe rc(8)?), along with a basic template script in a well
known place, then even a quite unsophisticated user could figure out how
to do something to the boot they'd never manage with an old-style /etc/rc.

> On the particular machine, the stuff in /usr/pkg was only installed through
> the pkg system. Some ofthe oldest things in there are:
> 
> -r-xr-xr-x   2 bin   bin     393562 Dec 21  1997 zsh
> -r-xr-xr-x   2 bin   bin     393562 Dec 21  1997 zsh-3.0.5
> -r-xr-xr-x   1 bin   bin     393562 Dec 21  1997 zsh.old
> -r-xr-xr-x   1 bin   bin      13978 Nov 19  1997 send-pr
> -rwxr-sr-x   1 root  kmem     36864 Nov 19  1997 top

Hmmm... with zsh.old in there I'm guessing you must have installed zsh
with a pkgsrc build from a poorly hacked pkgsrc module (which makes
sense given the date), and not installed it via a binary package....

But I don't understand what a bunch of binaries in /usr/pkg/bin have to
do with your pkg databases moving around.  The pkg database is normally
in /var/db/pkg, and that's where it's always been on my oldest
still-running machine (which is only a few months newer than the
examples you show above :-).  I upgraded apache on it just yesterday via
pkgsrc and had no problems.  So long as "pkg_info -L zsh" still shows at
least the first two files, and so long as "pkg_info zsh" still shows the
appropriate "Requires" list of dependencies (if any), and so long as all
those packages are still installed, and so long as "pkg_admin check" for
each doesn't report any problems, then your pkg database is still up to
date and consistent, and the installed files for those packages are all
still there (and still contain exactly what they did when the package
was installed, assuming the MD5 checksum was registered for the files at
that time).

(yes my "pkg_admin check" report is quite scary on my test machines, I
really need to newfs /pkg and really start fresh, but it's clean as a
whistle on all my production machines)

> When you do a "make upgrade" to upgrade a library, all applications that
> used that library are removed, and then the applications are supposed to
> be sucked down and rebuilt after all else is updated. I've seen applications
> removed and never rebuilt by pkg.

I never let pkgsrc make that kind of mistake on me -- I keep manual
track of what I'm doing, what needs to be rebuilt, and why; and then I
build binary packages once I've installed and tested the new software
and I make sure those packages register all the proper dependencies, and
then I upgrade my production machines with those binary packages.

> The pkg stuff deleted postgressql while I had a running database.

I take it you mean pkgsrc, not pkg_add.  pkgsrc is really only meant for
building packages from one static "release" of the whole tree.  If you
want to mess with upgrading a given machine with a constantly changing
pkgsrc, especially one that's riding the bleeding edge like -current,
then you have to be _VERY_CAREFUL_ -- there are no guarantees that it
will work and having a constantly changing set of dependencies breaks
all kinds of assumptions that pkg_add et al have hard-coded in them.  I
know this really isn't well documented, but that's no excuse.  If you
did a "sup", "cvs update", un-tar, or whatever of pkgsrc-current and
then typed "make update" for something on a production machine without
first finding out what might be deleted and hopefully rebuilt then you
only got what you deserved.

> So, only applications from the NetBSD distribution and pkg should be allowed?

What you've apparently tried to say here simply does not follow.  You've
made a very illogical leap and ignored again the explicit caveats I've
stated.

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