Hello,

Oh, no, another $$ worth ...

Some brief notes on what I look for when installing large packages (eg.
Ileaf, FrameBuilder, Ingres, AUIS, ...).  Most people won't look for (or
need) any thing like this.  If you are going to start packaging things,
you may wish to keep these points in mind.

While reading keep your salt grinder handy :-)

	o	Package install under their own top level.  It can also have a
		second `home' directory for scratch stuff.
		Eg /vend/ileaf-6.0 and /home/vend/ileaf (and a link
		/vend/ileaf -> ileaf-6.0).

	o	You can tell the installation procedure lies and it will believe you
		eg /vend/ileaf-6.0 is really /amd/dobson/fuji/vend/ieaf-6.0.
		ie packages that go INSTALL_DIR=`/bin/pwd` sux.

	o	Can be adminstered from an ordinary (dedicated) account.
		i.e. often get their own UID=GID.

	o	The installation point can be decided at installation time.
		If at all possible, please don't impose a hard wired
		directory.

	o	As far as possible, doesn't require *any* thing in a users
		environment to run.  i.e. /<xxx>/<package>/bin/<command>
		hopefull works.
			-> NO LD_LIBRARY_PATH stuff
			-> NO PATH
			-> NO Other variables
		If all else fails, /usr/local/bin gets a script that wraps
		up the mess.  (eg run-<package>).

		Suites of utilities are the exception (eg TeX, psutils, `gnuutils').

	o	Doesn't create potential name space polution problems by
			o	Requiring everything to have an
				alias in /usr/local/bin
			o	requiring ldconfig commands to
				find dynamic libraries
				*[NetBSD currently can't do this]*

	o	It's the end user, not the adminstrator, that decides which things
		to put into a PATH name space.

	o	Some times (just some times) I'll put `an alias' in
		/usr/local/bin.

	o	I can make the package accessable from a double click icon
		(and may be a menu entry).  Have look at VUE (HP) or ODE.


				Andrew

PS: Sorry, like "Charles M. Hannum" <mycroft@gnu.ai.mit.edu>, I can't
help with this but probably could manage a few comments.