#: From owner-current-users@NetBSD.ORG Wed Jul 26 23:14:06 1995
#: To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
#: Cc: current-users@NetBSD.ORG, explorer@iastate.edu
#: Subject: Re: /etc/default 
#: X-Url: http://www.public.iastate.edu/~explorer
#: Date: Wed, 26 Jul 1995 21:29:44 CDT
#: From: "Michael Graff" <explorer@iastate.edu>
#: 
#: 
#: This is not a good attitude.  Hard installs of everything is one of
#: the primary complaints everyone who runs Lamex uses as a justification
#: not to join the real world.

All the rest of the moderates here seem to be somewhat quiet :-)

We're looking for something in the middle, I believe (correct me if
I am wrong).

We don't want to have to do EVERYTHING by hand, yet we don't want things
predetermined for us.

Isn't that what _interactive_ or command-line-flagged scripts are for?
Doesn't "configure" kind of work this way?

The scripts should be written well enough that one should have to provide
a minimum of information at the onset, and yet they should not make bone-
headed assumptions on where things go (or worse -- unchangeable parameters
which *tell* you where you will *make* room for them!  I've run into a couple
of these in my levenure...).

If it "gets something wrong", it was poorly designed and needs to be
rewritten.  If you can't tell it where to put things, it was poorly
designed and needs to be rewritten.  If you can't just hand it some infor-
mation at the outset and walk away from it (including room for error
in designating a disk partition), it was poorly designed and needs to
be rewritten.  If it blows up, it was badly written and needs to be
redesigned...

There are good arguments on both sides of the fence.  Now what we need
to do is find the good arguments and merge them neatly.  A "configure"-
like startup would probably not be all that bad an idea.  It has its own
ideas of defaults BUT IT LETS YOU CHANGE THEM.  "Hints", I think configure
calls them.

					Just my (char) (0377 & 3),
					--*greywolf;


#: 
#: >On the other hand, I hate that sort of "automated" installation,
#: >because it always gets something wrong...anything from assuming it's
#: >being installed in /usr/local/<package-name> to assuming the C library
#: >lives in /usr/lib/libc.*.  When faced with something with an
#: >"automated" installation procedure, I usually pick apart the install
#: >script, figure out what it's trying to do, and then do that.  In some
#: >cases I fix the install script, in some cases I do it by hand.
#: >
#: >Thus, I look upon the traditional-BSD way as an advantage, because it
#: >discourages attempts to automate installation that way.
#: >
#: >					der Mouse
#: >
#: >			    mouse@collatz.mcrcim.mcgill.edu
#: 
#: --Michael
#: