Subject: Re: Ported software
To: None <current-users@NetBSD.ORG>
From: Andrew Cagney <email@example.com>
Date: 09/14/1994 15:22:09
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
o As far as possible, doesn't require *any* thing in a users
environment to run. i.e. /<xxx>/<package>/bin/<command>
-> 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
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.
PS: Sorry, like "Charles M. Hannum" <firstname.lastname@example.org>, I can't
help with this but probably could manage a few comments.