Subject: more on optional software (long!)

From: Hubert Feyrer <[email-masked]>

This is mainly an intro to the EasyInstall-scripts.

This goes to the amiga-mailing-list and to all who have compiled optional
packages for NetBSD/Amiga. Sorry if this is a bit lengthy ...

---------------------------------------------------------------------------

    Using and making optional packages available for NetBSD/Amiga
    #############################################################
                (C) Hubert Feyrer, September 4th, 1994

       Summary:
       ~~~~~~~~
       This document describes how optional packages should be
       structured so they can be easily installed and removed.
       Furthermore,  a method for simplifying the installation
       is  introduced and hints   on how to configure optional
       packages are included.

0) Contents
~~~~~~~~~~~
  0. Contents
  1. Introduction
     1.1 Format of packages
     1.2 Accessing packages easily
     1.3) Other things to do while installing packages
  2. The installation process
     2.1 Things done while installing
     2.2 Things done while uninstalling
  3. Configuring the installation process
  4. Notes on configuring packages
  5. Future plans
  6. Disclaimer & legal stuff
  7. Availability
  8. Final note

1) Introduction
~~~~~~~~~~~~~~~
As stated in an earlier posting, I'd like to see all optional packages
reside in their own directory below one common directory (/opt). Packages
are placed in subdirectories below /opt, with the directory name of the
package giving name and version of the package, e.g. /opt/fvwm-1.23f,
/opt/bash-1.14.1.

1.1) Format of packages
~~~~~~~~~~~~~~~~~~~~~~~
Below the package-directories, files are stored in the following
subdirectories:

 - binaries: 			bin
 - formatted man-pages: 	man/cat[1-8]
 - unformatted man-pages: 	man/man[1-8]
 - misc files: 			etc
 - libraries: 			lib
 - includes: 			include
 - info-files: 			info

Information for installing the package is provided in the subdirectory
"install", namely as a script "install.sh" for installation and
(recommended) "uninstall.sh" for removing the package.

1.2) Accessing packages easily
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Having several packages installed would force users to include serveral
bin-directories into their $PATH, get unwieldly long $MANPATHs, ... To
prevent this, files that are accessed by users are linked to some public
directories below /opt. The directories used are exactly the same as the
ones used inside the packages. Doing this has two advantages:

- easy installation of packages
- users have to include only one directory into their $PATH (/opt/bin),
  $MANPATH (/opt/man), ...

This document is intended to describe a mechanism for making packages
accessible via those public directories.

1.3) Other things to do while installing packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are also some more things to handle when installing packages,
namely:

 - installing X application defaults
 - making files setuid root
 - creating auxiliary directories (for more libraries, includes, ...)
 - Pre/Post-install scripts (not yet)

2) The installation process
~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've written some shell scripts that should help installing optional
(precompiled) packages on ones system by doing the things mentioned
above. All one has to do to configure the installation is to set some
variables in a (shell)script that will be uses for installation as
well as de-installation.

2.1) Things done while installing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The "install.sh"-script does the following things while making a package
publically available:

a) If application defaults are to be installed, figure out the directory
   where to put them. The following directories are searched:

    - /usr/lib/X11/app-defaults
    - /opt/X11R6/lib/X11/app-defaults
    - /usr/X11R6/lib/X11/app-defaults
    - /opt/X11R5/lib/X11/app-defaults
    - /usr/X11R5/lib/X11/app-defaults
    - $BASE/X11R6/lib/X11/app-defaults
    - $BASE/X11R5/lib/X11/app-defaults

    (BASE is the directory below which packages are installed, usually
     /opt, but can be changed, although this is not recommended)

   If no directory can be found, the user will be prompted to insert on.
b) Create /opt and additional directories (for includes, libraries, ...).
c) Link files specified from /opt/<package>/bin to /opt/bin. Same for files
   in etc, lib, man/man[1-8], man/cat[1-8], info and include. Directories
   that do not exist will be created.
d) Install X application defaults into the directory previously figured
   out.
e) Set specified files setuid root.

2.2) Things done while uninstalling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"uninstall.sh" performs the following tasks while removing the package from
public directories:

a) Find out directory for application defaults as described above.
b) Remove files from public directories: bin, etc, lib, man/man[1-8],
   man/cat[1-8], info, include. After that, directories will be removed if
   they are empty.
c) The X application default file is removed.
d) Remove misc directories for libraries, etc.

Please note: the package itself (/opt/<package>) is *not* removed!

3) Configuring the installation process
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The two scripts "install.sh" and "uninstall.sh" are expected to be placed
in a packages "install" subdirectory. This is also the place where the two
scripts look for a file "package" which describes the package.

The packag-file contains only definitions for some (environment) variables,
namely:

- BASE: Base of public directories. Defaults to "/opt" and should not be
        changed.
- PKG: Absolute patch of the package, usually "$BASE/package-name".
- BIN: Which files to link from $PKG/bin to $BASE/bin. Must be enclosed in
       "quotes" if more than one file is given (space-seperated).
- ETC: Which files from $PKG/etc will be needed in $BASE/etc? (Note: You
       should compile in /opt/packagename as base for packages, not
       /opt. This way you won't have to link files into /opt/etc.)
- LIB: Libraries of public interrest, relative to $PKG/lib. Additional
       libraries can be created by setting MISCDIRS (see below).
- MAN1: which unformatted man-pages to link from $PKG/man/man1 to
        $BASE/man/man1 (including ".1"-suffix!). Descriptions for general
        commands go here.
- MAN2: same as MAN1 (suffix: ".2"), just for system calls.
- MAN3: same as MAN1 (suffix: ".3"), just for C libraries.
- MAN4: same as MAN1 (suffix: ".4"), just for device drivers.
- MAN5: same as MAN1 (suffix: ".5"), just for file formats.
- MAN6: same as MAN1 (suffix: ".6"), just for games.
- MAN7: same as MAN1 (suffix: ".7"), just for miscellaneous things that
        don't fit else where.
- MAN8: same as MAN1 (suffix: ".8"), just for system administrative
        commands.
- CAT1: which formatted man-pages to link from $PKG/man/cat1 to
        $BASE/man/cat1 (including ".0"-suffix!). Descriptions for general
        commands go here.
- CAT2: same as CAT1 (suffix: ".0"), just for system calls.
- CAT3: same as CAT1 (suffix: ".0"), just for C libraries.
- CAT4: same as CAT1 (suffix: ".0"), just for device drivers.
- CAT5: same as CAT1 (suffix: ".0"), just for file formats.
- CAT6: same as CAT1 (suffix: ".0"), just for games.
- CAT7: same as CAT1 (suffix: ".0"), just for miscellaneous things that
        don't fit else where.
- CAT8: same as CAT1 (suffix: ".0"), just for system administrative commands.
- INFO: files to link to $BASE/info. Modification of "$BASE/info/dir"
        should be done by some smart post-processing script (once these are
        implemented ;-).
- APPDEF: Application default files, relative to $PKG, usually
          "lib/XApp.ad". Suffix ".ad" will be stripped in link.
- INCLUDE: Files to link into $BASE/include, e.g. for libraries like
           readline. Additional subdirectories can be created by setting
           MISCDIRS.
- SUIDROOT: Which files (relative to $PKG) to make setuid-root (just in
            case tar goofed some protections/ownerships).
- MISCDIRS: Which additional directories to create under $BASE. Usually for
            grouping includes or libraries.

4.) Notes on configuring packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When compiling optional packages, make the base-directory "/opt/package",
not "/opt". By doing so you don't have to put every single file into public
directories, but only the ones of interrest for users (usually binaries and
man pages).

Please do *not* upload modified sources of freely distributable
programs. Send them to the authors instead so the changes will be
incorporated in the next release.

5.) Future plans
~~~~~~~~~~~~~~~~
There are two things I can think of that might be useful:

 - Pre/Post-install-scripts which will be run before/after the installation
   to backup files, etc.
 - Some smart script to edit config-files. Useful for adding info-files to
   the dir-file or think if one wants to install wu-ftpd: editing
   /etc/inetd.conf by hand. :-/

6.) Disclaimer & legal stuff
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use at your own risk. All rights reserved.

7.) Availability
~~~~~~~~~~~~~~~~
I'll put this all together into a package "EasyInstall-1.0.tar.gz" and place
it into /pub/NetBSD-Amiga/contrib on ftp.uni-regensburg.de. I'll place this
document into the docs-directory as "Packages.txt".

8.) Final note
~~~~~~~~~~~~~~

Call for discussion!

What do you think about all of this? Are the two scripts useful, will
anyone use it? What can be improved? How about the method for detecting the
appdef-dir? Are there any public directories I've missed?

Tell me! Either via private email ([email-masked]) or
the NetBSD/amiga mailing list ([email-masked]).

Enjoy,

       Hubert

-- 
=============== Hubert Feyrer ============================================
      Weekdays: Rennerstr. 19, D-93053 Regensburg,  Tel. 0941/701788
      Weekends: Bachstr. 40,   D-84066 Mallersdorf, Tel. 08772/6084
      Internet: [email-masked] == IRC: hubertf
==========================================================================
    Click <A HREF="http://dusk.rz.uni-regensburg.de/~hubert">here.</A>
                           (soon to be back!:-)

---

From: [email-masked] (Ty Sarna)

In article <9409042345.ZM28815@rrzc1> Hubert Feyrer <[email-masked]> writes:
> [...]

Uh... why invent yet another wheel? There are already a number of widely
accepted systems for doing this stuff. The pkg_* tools from FreeBSD,
depot, SWINST, etc. All are freely availible, and all do everything your
scheme seems to and more.

Besides, this kind of thing should be a NetBSD issue, not a NetBSD/amiga
issue. Why not bring it up on the tech-install list?

Personally, I wish NetBSD would adopt either SWINST or (preferbaly in my
opinion) the pkg_* tools and just go with them. 

-- 
Ty Sarna                   "You can lead a gift horse to water but 
[email-masked]          you can't make him look you in the mouth"

---

From: Charles Ewen MacMillan <[email-masked]>

On Mon, 5 Sep 1994, Hubert Feyrer wrote:

> Date: Mon, 5 Sep 94 00:51:17 +0200
> From: Hubert Feyrer <[email-masked]>
> To: Charles Ewen MacMillan <[email-masked]>
> Cc: [email-masked]
> Subject: Re: more on optional software (long!)
> 
> > tree for ease of de-installation, there is already a well known
> > convention for doing so.
> >
> >         /usr/local
> >         /usr/local/bin
> >         /usr/local/lib
> >         /usr/local/man
> >         /usr/local/etc
> 
> Well, on the systems that I know, conventions for /usr/local are slightly
> different. Under /usr/local, you actually *copy* the files into the various
> directories. By doing so, you end up with a directory full of files that you
> don't know where they belong to. By using links, you can find out and still
> have everything in it's own place.
> 

 One can already do that with /usr/local.
------------------------------------------------------------------------

lrwxrwxrwx  2 root    393216 Apr 13 04:36 perl -> /work/src/perl/bin/perl
lrwxrwxrwx  1 root     47456 Sep  4 12:34 pico -> /work/src/pine3.90/bin/pico
lrwxrwxrwx  1 root        16 Sep  4 12:35 pine -> /work/src/pine3.90/bin/pine

 Many people I know who do development already leave software that is 
either in development, or likely to be soon upgraded in place in its source
directory, so that re-installation is a simple matter of installing a new
link to the correct source directory.

> 
> >  Adding yet another bin path, and lib path, slows down executable search
> > time, which is considerable in light of the fact that NetBSD already has
> > /bin:/usr/bin:/sbin:/usr/sbin and typically /usr/local/bin:$HOME/bin:.
> > as part of the exec search path.
> 
> It's not adding another one. Replacing /usr/local/bin by /opt/bin wouldn't cost
> anything. :-)
> 

 Why replace it? Users _look_ in /usr/local/bin for new and site specific 
binaries.

 It can hardly be _replaced_ on systems that are already up and running 
either. If the idea is a replacement, why change the name?

> >  For systems which have shared disks (I have 1 /usr tree now for 3 machines)
> >  this poses the added problem of yet another link, potentially causing
> > conflicts with file exports.
> 
> There's one thing that *might* slow down things, and that's the fact that the
> symbolic link from /opt/bin to the package's bin-directory has to be traversed,
> but I want to do some benchmark to find that out. Any suggestions?
> 

 Conflicts with extra links do not just slow things down, they mean 
re-writing export trees.

> 
> >  I think it is an excellent idea, except that the conventional /usr/local
> > division should be used rather than the novel and arbitrary /opt.
> 
> As said above: new rules, new names. ;)

 They are not new rules though, and there are already existing systems 
which use something very similar, which is something users have come to 
expect.

 My only argument is that the name change serves no purpose, when this is 
already how /usr/local/* is used.

Charles Ewen MacMillan  | Tezcat.COM - Wicker Park 
  <[email-masked]>    | Offering Internet Access 
Modem: 312-850-0112/0117| Via Interactive UNIX to 
Voice: 312-850-0181     |    the Chicago Area.
WWW: http://tezcat.com/ | Mail: [email-masked]

---

From: Hubert Feyrer <[email-masked]> "Re: more on optional software (long!)" (Sep 5, 7:48am)

> > If one wants, he can still hold "local" software (think about the meaning of
> > this word!).
> >
>
>  The meaning of the word has nothing to do with its standard usage.
...
>  This is the normal usage of this subdirectory on almost every BSD
> derived system I have seen, ever, and I have seen many a BSD derived system.

As you seem to intend using NetBSD/amiga(!) in a rather wide-spread network,
this seems rather strange to me. One usually has software which *all* machines
on the network use, and there are also some applications that are run on only
one or a few machines.

>  Well, as an administrator, I will maintain that one of the most
> important parts of avoiding additional maintenance work is not instituting
> arbitrary changes to the layout of the disks.
>
>  If you doubt this, change the path to someone's home directory after
> they have been using it for a year, and see how much angry mail and phone
> calls you will get from them.

This is not changing some existing direcory-structure, but - as I've pointed
out several times previously - a new scheme with new rules. Is this that hard
to understand?

It's not just putting stuff in /opt instead of /usr/local! It's also some
thoughts on (de)installation. What did the systems you saw do in the latter
case? just rm whatever seems to belong to a particular package?

>  My point again, _why_ change it?

Just in case, I'm going to repeat myself once more:

It's not just putting stuff in /opt instead of /usr/local! It's also some
thoughts on (de)installation.

>  If a disk, is exported to 5 machines, and I must remove that disk from
> its current install point as seen by the operating system, and move it to
> a new mount point, then I must update the mountlists on each of the
> machines in question, and dependent upon what operating system they are
> running, I must reboot them.

True. And if you start a new installation from scratch - as quite some people
will hopefully do with NetBSD - why not use a new scheme from the beginning.
That way noone has to modify existing paths.

>  Installing a new sym-link to the directories in question, is costly and
> foolish, as eventually one recieves the notice that there are too many
> levels of symbolic links.

Why is it clostly and foolish? What does it cost, or better: how much? Will
anyone notice it? I won't have the time trying this out before next weekend,
but if you could give me some facts until then, you could really make me glad.

On symbolic links: how far may they be nested right now? 16? 256? C'mon, this
is not an issue here! It's just 1 symlink (more).

>  Symbolic links to directories also greatly irritate and confound users
> who have not mastered the "cd" command.

If "cd" confuses someone, installing and even using a pre-compiled package
either in /opt or in /usr/local will *kill* him, so what. :-)

>  If symlinking the directories is not an option, then moving the
> directory accross the filing system is the only other alternative, and
> this is out of the question save by changing all mountlists on all machines.

How many Amigas running NetBSD are we talk of? More than two?

>  Aside from the example which I grant, of pre-compiled software, I see no
> utility for a new directory tree whatsoever.

This is the only one I'd like to use this for, and I guess it's good enough.
Who doesn't want X or just "screen" to get some replacement for virtual
consoles? Also someone might want to run Emacs in preference to vi.

Now imagine someone just succeeded in installing a basic NetBSD system. He has
the option to install some packages he'd like to run, and I don't think he
cares moch from a *users* point of view where the packages will be places, as
long as one can use them.

BTW, have you tried replacing the system's (g)cc? It's rather nifty, as any gcc
you build on your own will search in system-places and will find some files
which don't belong to it. In order to remove (g)cc, you have to change quite a
number of things.

>  I think the arguments that I see against far outweigh any percieved
> benefits of such a re-structuring, and that NetBSD as a project is served
> best by sticking in disk layout as close as possible to standard for BSD
> systems everywhere.

Sticking to standards is good, but there are sometimes different standards for
the same thing. Just think about POSIX in NetBSD.

-------------------------------------------------------------------------------

Gosh, we're WAYS off topic... all I want is the following:

There are already quite some packages under contrib here (ftp.uni-regensburg.de
/pub/NetBSD-Amiga), and I want some simple scheme for users to add and
remove(!) those packages from their system.

You should know by now what I figures out as a solution and you obviously don't
like it. What I'd like to have from you now is some idea how we can handle
this.

I don't really care if it's /opt or /usr/local. I want a useful scheme behind
it. Tell me one.

Hubert

---

From: Charles Ewen MacMillan <[email-masked]>

On Mon, 5 Sep 1994, Hubert Feyrer wrote:

> Date: Mon, 5 Sep 94 10:40:42 +0200
> To: Charles Ewen MacMillan <[email-masked]>,
>     Hubert Feyrer <[email-masked]>
> Sure you can, but one usually *does* not, as install-scripts of FD software
> assume /usr/local as the base-directory and then just *copy* their files into.
> 
> I have to admit that I haven't seen this before. Also, it's possible with links
> to "working areas" that the user may end up with a bogus binary. Not very nice.
> 
> Furthermode, I think of /opt as a place where to put already compiled software
> which is ready to run, giving less experienced sysadmins a chance to install
> things that will run "out of the box".
> 

 When we constructed the basis of our filing system tree here, we did so 
only after comparison with the half dozen accounts on which I had 
accounts, on several different operating systems, and platforms, and the 
observations of different filing system trees made by various staff members.

 There is no coincidence whatsoever that when the /usr/gnu subdirectory 
was dropped more or less from the standard tree, that the standard tree 
then matched the configuration of this site, with /usr/local as the 
parent of the tree for softwares compiled, or even just installed locally.

 The meaning of the word "local" has no more to do with its application 
in this context, than the word "kernel" as it is applied in UNIX refers 
to a piece of grain.

> It's a replacement from the user's point of few (another bucket full of
> programs to use), but it's a difference to the sysop which has to maintain the
> wohle mess.
> 

 The administrator of a site does not simply go around changing the paths 
for executables, without expecting to be forced to explain it repeatedly, 
and fixing the .cshrc files of the pitiful users who have used absolute 
paths and cannot log on.

 The first order of reducing work, is to recognize that a confused user 
who cannot log in, is more work than rebuilding an operating system some 
times.

> What do you mean by this? I don't understand.
> 

 Rebooting one's machines is a non-trivial matter on a site which is in 
constant use. I have had to reboot only one non-netbsd machine ever as a 
result of a change instituted on a netbsd machine, and I like to keep it 
that way. I am sure others do as well.

> True, and as I've stated previously, it is *not* the same (from the
> administrative point of view).
>

---

From: Hubert Feyrer <[email-masked]> "Re: more on optional software (long!)" (Sep 5, 2:47am)

>  Conflicts with extra links do not just slow things down, they mean

Do you have any experience with this? Ran any benchmarks? I'd like to see it,
before I start judging on that.

Hubert

---

From: Hubert Feyrer <[email-masked]> "Re: more on optional software (long!)" (Sep 6, 5:04am)

Hi Ty,

> scheme seems to and more.

I didn't notice there are such tools. All I know is "swdist", which just cares
about bringing software to your disk, but needs extra scripts to do additional
installation on one's disk.

This is why i wrote the described scripts.

> issue. Why not bring it up on the tech-install list?

OK, I didn't notice there's a list for this, too. As far as sun-lamp is up
again, I'll subscribe.

> opinion) the pkg_* tools and just go with them.

Where can I find them? I'd surely like to try them out!

Thanks for the pointers,

                      Hubert

---

From: [email-masked] (Rob Healey)

> I don't really care if it's /opt or /usr/local. I want a useful scheme behind
	In a word to make the rabid BSD's howl "FOWL!" I would like to
	suggest something much like the SVR4 pkg system. Individual packages
	can be installed whereever they damn well please AND the system
	mangler can decide at install time if they want to use the default
	tree OR one of there own choosing! You can then use pkginfo to
	find out what's installed, at what level and what the componants
	and OTHER DEPENDANT PACKAGES are to that package;i.e. does this
	package depend on another being installed or does some other
	package rely on this package being installed?

	Damn nice system for those of us who get stuck installing hundreds
	of patches on tens of machines for a living... Not to mention
	the occational application or OS. As soon as those #%$#^#$ tar
	only installs for Solaris/SVR4 disappear the better!!!!! But thats
	just a personal pet peeve of mine, I don't WANT to hunt down through
	27 gigabytes, YES gigabytes, to find every last scrap of some
	braindead applications tar/script install. Give me pkg format
	where all I have to do is a "pkgrm WordFoo9000" and it all just
	deinstalls and works.

	Of course we're talking a hacker OS for NetBSD so I sincerly doubt
	anything as clean and logical as pkg will ever find it's way in
	to the system; It's against the TRUE hacker code for things to
	JUST WORK!

	Enough rants for now,

		-Rob

---

From: [email-masked] (Ty Sarna)

> 	suggest something much like the SVR4 pkg system. Individual packages

This is exactly what FreeBSD's pkg_* tools do. It would be great if
NetBSD would adopt them too.

---

From: Charles Ewen MacMillan <[email-masked]>

On Mon, 5 Sep 1994, Hubert Feyrer wrote:

> Date: Mon, 5 Sep 94 15:49:40 +0200

 Our current NetBSD machines share everything except for / and some 
directories in /var of course. It does not matter if all the programs
contained on /usr are used on all machines, there is no reason to 
export individual directories to systems that have near identical 
architectures.

 My argument is however not based on how my system is set up, but rather 
on how BSD systems in general are set up.

> out several times previously - a new scheme with new rules. Is this that hard

 I am not misunderstanding what you are suggesting at all. I am arguing 
merely that the novelty is unneccessary, and could in fact prove problematic
on some systems.

> case? just rm whatever seems to belong to a particular package?

 De-installation can take place from any directory. Look at a program 
 like procmail which simply records what it did, and where.

> That way noone has to modify existing paths.

 No one need ever modify existing paths if software is installed under 
/usr/local either.

> is not an issue here! It's just 1 symlink (more).

 Chasing a link to its end, is a usage of CPU. Some programs break 
when they are made to read a link. In general, sym-links are considered
sloppy.

 I routinely create too many levels of links using normal install scripts.

 Yes, people will notice it, see below.

> either in /opt or in /usr/local will *kill* him, so what. :-)

 You are thinking of this entirely from the perspective of a developer or 
maintainer of such a system, rather than from the perspective of a user.
A user does not rationalize these sorts of problems, they call you on the 
phone and say your disk is broken.
 
 I have to think of it from the perspective of a user first. For a user, 
there is nothing more confusing than to type "cd .." from:
 
               /usr/local/gnu

 and to wind up in:

              /opt/packages/gnu

 Most users cannot read well enough to understand popd and pushd from 
csh, assuming that they are even using a Berkeley based shell.

 For other arguments against symlinks, read the manual pages for ln, 
readlink, and all related pages in SunOS. The idea is very much the same, 
even if the problems are fewer under NetBSD than SunOS.

> How many Amigas running NetBSD are we talk of? More than two?

 Two at the moment, three next week. I have two spare ethernet cards, so 
it seems appropriate to put machines on them. What is the difference how 
many machines it is for?

 If one thinks about these things from the perspective of "Well, who is
going to use it in a production or heavy-duty setting?" then in fact no
one ever will. This has always been a problem with the implementation of 
other softwares to the Amiga that I have seen. I can give you reams of 
examples in private mail if you like.

> consoles? Also someone might want to run Emacs in preference to vi.

 X is usually installed in its own directory, screen I _always_ see 
installed in /usr/local/bin, even on the SVR4 systems I have thrown up on.
If a user has the wit to place /usr/local/bin in their path, and types 
screen, and it tells them "unknown command" they think the program does 
not exist on the system.

> long as one can use them.

 Well, this is I think the difference in how you and I are looking at 
this problem. I think you can consider my arguments to be fairly typical 
of those that will be raised by anyone who is using this software on a 
running site, with active users.

> I don't really care if it's /opt or /usr/local. I want a useful scheme behind

 Well, I like the idea of the installation script just fine. I guess I 
would argue that to begin with, any such scripting should either 
understand command line arguments, for instance, what point to use as the 
parent of the installation tree, like "imake" does, or it should be 
configurable from a single line in the install script.

 All of my argument is based on the idea that there are already users who 
have .cshrc or .profile files, and that updating them would prove to be a 
greater difficulty than using "find" to find all of the parts of a given 
distribution.