Bug: install.sh for Solaris

David Lee t.d.lee at DURHAM.AC.UK
Wed Jun 30 17:17:47 IST 2004


On Tue, 29 Jun 2004, John Rudd wrote:

> Here's the relevant part of the output of install.sh:
>
> > You appear to have 2 versions of Perl installed,
> > the normal one in /usr/bin and one in /usr/local.
> > This often happens if you have used CPAN to install modules.
> > I strongly advise you remove all traces of perl from
> > within /usr/local and then run this script again.
>
> What it should do:
>
> a) check to see if one of them is a symlink to the other (in this case,
> it is: /usr/bin/perl is a symlink to /usr/local/bin/perl
> b) not assume that /usr/bin is authorative (which it is doing by
> recommending that all traces of the one in /usr/local be removed: very
> poor recommendation, considering that's the _correct_ installation of
> perl)
> c) check to see which one might have some or all of the correct modules
> in place
> d) ask, ask, ask what the right behavior should be.  In this case:
>    "do you wish to:
>       1) proceed with /usr/local (default)
>       2) proceed with /usr/bin
>       3) exit so you can 'fix it'
>       enter choice:"

John: I understand Julian is on holiday this week.  In his absence, I'll
do my best to address the "install.sh for non-Linux" points (as it was
mainly I who persuaded Julian to do this generalisation of "install.sh"
from Linux-only to general UN*X).

Firstly, "install.sh" was written for and refined within a Linux context
over a considerable time.  Other OSes do things differently (e.g. no RPMs,
different "/usr/local" conventions and understandings).  So the current
state of "install.sh" for non-Linux is, not surprisingly, not as well
refined.  (That is, it's new, and has some rough edges.)  But I believe
the aim is to refine it, but to keep to having a single, general
"install.sh" (which then invokes various OS-dependent or feature-dependent
parts).  I understand that Julian would rather not go down the full-blown
"autoconf" and "./configure" route; nevertheless similar ideas and
concepts would apply.

> Failing and then forcing you to re-run without the sanity check
> ("./install-sh ignore-perl") is a poor choice of design.

My personal view on this "which version of perl" is that "install.sh"
probably shouldn't ask the question (i.e. probably shouldn't be
interactive, pausing for input).  Rather it should probably allow
arguments to the effect of "./install.sh --perlpath=/foo/bar".

--

:  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



More information about the MailScanner mailing list