[ On Tuesday, May 2, 2000 at 16:27:26 (-0600), Jones, Carrie (Bowen) wrote: ]
> Subject: RE: Proposed rc.d changes....
>
> Greg, I have no idea if you are deliberatly trying to post inflamatory
> comments, or if you are just caught up in the excitement of ideas that
> have been bouncing around for the last day, but I suggest that you
> take a good long look at what you just wrote. I believe that the
> "charade" of trying to isolate "third-party software" was done for
> good reasons.

I too once believed that it was sane, and perhaps even necessary, to
isolate third party software into a hierarchy separate from system
files.  Over the years I've waffled several times on just how "pure"
such a separation must be.  However after battering my head against the
wall with NetBSD and FreeBSD on this and related issues several times I
finally realized that the only reason I'd ever tried to keep things
apart was so that I could tell just by looking at them where they came
from and what should be done about them before and/or after a system
upgrade.  That realization wasn't finally hammered home by any one
specific thing -- it was a slow process brought on by finally having
full system source, having a half-decent package management system,
gaining an ever deepening understanding of software configuration
management issues, and so no.

What it all boils down to is that with a decent package management
system there's literally no *need* to keep add-on stuff separate from
system stuff -- it's always "trivial" to identify the origin of
something and to know what to do with it during an upgrade process.

Furthermore I've discovered much to my joy that my expectations about
how end-user and "end-administrator" types react to a unified system
configuration has been more than confirmed.  For example I had set up a
SunOS-4 server for a client about 5 years ago with tons of add-on
software.  I was extremely careful to isolate all of the add-on stuff
into /local on that machine (to the extreme with /local/{etc,var}, etc.)
They were quite happy with that and it certainly helped to justify the
amount of time I took to set it up for them -- they were able to see
instantly how much effort I had gone to in making their system more
useful than a base OS install would have left it.  However after
replacing that machine with a small farm of NetBSD servers last year
they have been experssing their profound gratitude to me for having
integrated all of the software into one common hierarchy (i.e. I set
PREFIX=/usr and used pkgsrc exclusively).  Since they are not expert
Unix administrators (yet :-) they find they spend much less time trying
to figure out how something works and where the related config files are
located.  The one thing that still mystifies them is X11, and though not
entirely because it lives in its own hierarchy I'm sure that's a good
chunk of the reason.  Given this experience, plus all of the software
configuration managment issues that this integration solves, I would
have to say that the benefits of it far outweigh any advantages there
might be in keeping things physically/logically isolated.  Indeed even
the amount and complexity of the add-on software is still easily
revealed with a simple run of "pkg_info"!  ;-)

(note that if you never plan to upgrade the system then none of this
matters, period -- just hack away and be happy!)

There are still some minor issues to work out, such as what to do when
an add-on package has filenames that clash with system filenames.  There
are  several ways to deal with this issue, of course.  Note that once
the system is fully package-ized the problem becomes a bit simpler
because it's reduced into being identical to what happens now when two
packages have conflicting filenames.

BTW, on my development systems I still keep a separate /local hierarchy
because I want to be able to play around in there, but that's because
I'm solving a different problem in that environment....

> I am (of course) not all knowing and seeing so please educate me if you feel
> I am ignorant, but here is my datapoint. I do not want to have third party
> config files in /etc. EVER.

You really have to ask yourself *why* this is so.

> I am running on less than new architechtures and if you put third
> party config files in /etc, it will require even LONGER to reboot when
> I've got a problem.

that doesn't make sense at all -- it matters not where the stuff is if
it all has to be started up at boot time.  you could keep every package
in separate hierarchies (i.e. almost like Sun's /opt ;-) and it wouldn't
really make much of a difference (in fact that might even be slower! ;-).

> and reinstall will become a nightmare.

Not with a package management system it won't.

A pure re-install is easy, and even easier if you've been dilligent and
kept /etc/changelist up-to-date with all of the add-on config files (yes
this updating should be semi-automated).  So long as you've got an
easy-to-use/access backup of your localisations (eg. an up-to-date
mirror of /etc on some other media/machine/whatever) and a perhaps a
backup of your user files, you just re-install, look at your backups to
get a list of all the packages that had been installed (this would be
easier if /etc/daily did a "pkg_info > /etc/packages") and re-install
all of them too, and finally you restore your localisations (and your
user files if need be), and, voila, you've got a completely re-installed
copy of your original system.  Having /etc/changelist up-to-date means
that you've got at least three copies of all configuration files on all
of your full backups.

Even an upgrade is not too hard, though as always there's this three-way
merge problem that's an absolute nightmare if you've not got original
*and* modified copies of all of your config files.  With a NetBSD
upgrade you've often got the advantage that the new release might come
with a script to assist in the system upgrade.  You still have to
de-install and re-install all your packages if you want to be sure
you've squished all of the system bugs that might have been compiled or
linked into any package programs.

> Part of the charm of NetBSD was that it supports hardware and
> configurations that no one else in their right mind would even
> concieve of supporting anymore. But for educational institutions and
> people like me who don't have the money for latest and greatest toys,
> and we have to deal with whatever we are given, NetBSD is a life
> saver, right now anyway.  Please also keep that in mind. Some of the
> things that are proposed sound like they will make NetBSD much more
> attractive to the mainstream niche. What about the rest of us?

There's a *HUGE* difference between catering to weird and rare hardware
and catering to weird and rare system configurations.  One does not
necessarily derrive from the other and as I'm sure you're aware the
latter is much easier to do manually on a one-off basis than the former!

> Hope this doesn't throw too much sand on your enthusiasm, I really do
> appreciate the time and effort you spend on things. I know I've said
> it before, but I'm going to keep saying it because I feel it needs to
> be said.

Not at all!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>