Xref: utzoo comp.unix.admin:1266 comp.unix.large:238 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!sei.cmu.edu!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!wally+ From: wally+@andrew.cmu.edu (Wallace Colyer) Newsgroups: comp.unix.admin,comp.unix.large Subject: Re: Interesting Questions Message-ID: Date: 17 Mar 91 17:53:53 GMT References: <1991Mar12.005158.20343@erg.sri.com> <6Q.9Z1A@xds13.ferranti.com>, <1991Mar17.045714.2709@cbnewsh.att.com> Organization: Computing Systems, Carnegie Mellon, Pittsburgh, PA Lines: 24 In-Reply-To: <1991Mar17.045714.2709@cbnewsh.att.com> > *i) What would a vendor install script that you didn't hate look like? The biggest problem we have with vendor install scripts is that they do not fit into our rather complex installation and release control environment. We install into one location, release to another, and finally use the software from a third. This means that the installation script must at a minimum support the idea of a DESTDIR and a TOPDIR. DESTDIR is the path to install into and TOPDIR is where it will finally live so that any hard coded paths can be constructed even though the stuff it still not in the proper location. In addition, the directories within the hierarchy under TOPDIR need to be changable. If one application is already using TOPDIR/lib/mumblefoo I need to be able to change it so that the new application which wants to use that same directory can use TOPDIR/lib/mumblefred instead. Assumptions about the environment need to be abstracted as much as possible and documented. When ever possible modifiable scripts should be allowed for services like printing and mail. -Wallace