Bug: install.sh for Solaris

[David Lee]

On Wed, 30 Jun 2004, Kevin Spicer wrote:

> On Wed, 2004-06-30 at 22:10, John Rudd wrote:
> > > Rather it should probably allow
> > > arguments to the effect of "./install.sh --perlpath=/foo/bar".
> >
> > I like that idea.  A lot.  Errors could end with "See ./install.sh
> > --help" so they could see their options, and then they could assert
> > settings instead of just turning some tests off.  I like that idea a
> > lot.
>
> When I wrote the non-rpm install script for MailScanner-MRTG I did it
> that way  (--help and all) you'd be amazed by...
>
> 1) How many options even a simple program can have
> 2) How long the script ends up

Ah!  That's where "autoconf" really helps.  (I haven't looked at MS-MRTG,
have you considered autoconf for that?)


The package maintainer writes a relatively short "configure.in".  The
package distributor uses autoconf to generate a "configure" (possibly
long) automatically from that.  The local sys.admins. (thousands of them)
simply use that "configure" and "make".  Those few of us who want to
produce patches related to configuration and distribution geekily peek and
tweak inside that "configure.in".


> 3) How many people either
>   3a) don't read the install docs, install with all the default settings
> and then complain about it putting things in the wrong place

"configure" (autoconf) etc. is reasonably well-known these days.  The
defaults are usually reasonable for most of the people most of the time.

Folk who don't at least skim-read an "INSTALL" ... well that's their
problem, so long as we have set reasonable defaults (see above).


>   3b) do read the install docs, customise everything in sight, complain
> because it doesn't work

Again, our job is to get reasonable defaults for most people most of the
time.  At least the "mangle it because I can" brigade can be reaqsonably
requested to provide some useful "under the bonnet" technical feedback.

>   3c) Don't even notice the install script, install it the way they
> always did, complain because you've added some critical file and not
> told them where to copy it to.

Hence most packages provding some sort of summary of recent changes,
suitable for skim-reading.

> With hindsight I'm inclined to think this might not be the best way.  At
> least with configure and make most users will have portable skills from
> other installs.

The way I'm suggesting is intended to be compatible with any future
migration towards configure and make.

Hope that helps.


--

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 334 2752                  U.K.                  :

-------------------------- MailScanner list ----------------------
To leave, send    leave mailscanner    to jiscmail at jiscmail.ac.uk
Before posting, please see the Most Asked Questions at
http://www.mailscanner.biz/maq/     and the archives at
http://www.jiscmail.ac.uk/lists/mailscanner.html