gamiddle@maytag.waterloo.edu (Guy Middleton) (09/26/90)
In article <26645@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > In article <1990Sep19.144819.12179@dg-rtp.dg.com> hackwort@dg-rtp.dg.com (Brian Hackworth) writes: > >We can divide third party packages into two parts: > >the part which is the same for all hosts, and is therefore > >shared (an example is the /usr/bin/cat executable); and > >the part which is unique to each host (an example is /etc/passwd). > > I would break this even further: the part that is the same for all > hosts *regardless of architecture*; the part that is the same for > all hosts of the same architecture; and the part that is always unique. We have a very grandiose software installation doctrine here, and tend to subdivide yet further, into these categories: same for all hosts same for hosts of the same architecture same for hosts that share a community of users (an NFS server plus its clients, for example) same for hosts within an administration unique to a host spool files (in theory, spool files could be any of the last three types, but in practice here are merely a subset of the files unique to a host) Whenever we encounter an obstacle in the organization, we invent a new file type :-(.
les@chinet.chi.il.us (Leslie Mikesell) (09/27/90)
In article <1990Sep26.043825.26682@maytag.waterloo.edu> gamiddle@maytag.waterloo.edu (Guy Middleton) writes: >We have a very grandiose software installation doctrine here, and tend to >subdivide yet further, into these categories: The initial installation of a particular package is rarely a difficult problem because at that point the rest of the system is likely to be fairly stable and the installer can concentrate on the changes this particular package is making. The difficult part comes when (a) you upgrade the OS and the package touches some of the base system files (perhaps replacing /bin/mail with something reasonable on a sysV machine or the like) or (b) you want to move a package in its current state to a different machine (keeping initialized data files, etc.). How do you tell which pieces belong to which package, and in what order to reconstruct things? Les Mikesell les@chinet.chi.il.us
peter@ficc.ferranti.com (Peter da Silva) (09/30/90)
In article <1990Sep26.210617.12193@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > [when upgrading the system]. How do you tell which > pieces belong to which package, and in what order to reconstruct > things? You run the package's remove script (built at install time, so it knows the configuration), remove it, and re-install after the upgrade. What, you don't supply a remove script? Shame... -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
les@chinet.chi.il.us (Leslie Mikesell) (10/03/90)
In article <9-26933@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> [when upgrading the system]. How do you tell which >> pieces belong to which package, and in what order to reconstruct >> things? >You run the package's remove script (built at install time, so it knows the >configuration), remove it, and re-install after the upgrade. I've tried that, and often the remove script would remove all traces of the package, including the things I had spent a few months configuring exactly the way I wanted. Then there was one (must have had something to do with AT&T starlan...) that offered to save the configuration database but then the release notes for the upgrade said something like: "Answer 'no' to the prompt 'Do you wish to restore the saved configuration?'". >What, you don't supply a remove script? Shame... Things have gotten better recently, but I still don't trust scripts that offer to remove my files. I just wish that there were standard places for the set-up files with provisions for installed base copies, network wide copies, local system copies and per-user copies. It's one thing for a guru to philosophically assert that there should be no arbitrary restrictions on filenames or placement - it's something else to force everyone who installs a unix machine to re-invent a reasonable layout. If "installed" files lived in one place and "custom" files were elsewhere, an install script could just plop all the standard files into place and then offer to update any custom setup files it found if the old ones don't work as-is. Les Mikesell les@chinet.chi.il.us
peter@ficc.ferranti.com (Peter da Silva) (10/04/90)
In article <1990Oct02.183010.23173@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <9-26933@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >> [when upgrading the system]. How do you tell which > >> pieces belong to which package, and in what order to reconstruct > >> things? > >You run the package's remove script (built at install time, so it knows the > >configuration), remove it, and re-install after the upgrade. > I've tried that, and often the remove script would remove all traces of > the package, including the things I had spent a few months configuring > exactly the way I wanted. So save the configuation files off yourself. We do that, but the apps people seem quite happy to write the configuration down and do it by hand all over again. Package vendors: provide a simple text file for config data, and document it! > Things have gotten better recently, but I still don't trust scripts that > offer to remove my files. I just wish that there were standard places > for the set-up files with provisions for installed base copies, network > wide copies, local system copies and per-user copies. A-men. At least on System V there's a standard place for init scripts, and some packages do their customisation there. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
jmsellens@watdragon.waterloo.edu (John M. Sellens) (10/18/90)
In article <1990Sep26.043825.26682@maytag.waterloo.edu> gamiddle@maytag.waterloo.edu (Guy Middleton) writes: |We have a very grandiose software installation doctrine here, and tend to |subdivide yet further, into these categories: In article <1990Sep26.210617.12193@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: |How do you tell which |pieces belong to which package, and in what order to reconstruct |things? We install all our software off to the side, under a hierarchy called /software. OS upgrades can take place independently of this, modulo the need to update our additions to match OS changes. Each software "package" is in a separate hierarchy under /software (e.g. /software/gcc /software/tex etc.), and each package has an Install script in it. Those packages that have to mess with or replace standard system files do it in the Install script, so if the OS gets updated, the Install script can be run and all is well again. Yet more information: Each package has a maintainer associated with it, so if you have a problem with a particular set of software, you know to contact the person named in the /software/package/.admin/Maintainer file. Packages can also have system config file fragments (e.g. /etc/services entries, /etc/inetd.conf entries, cron entries, /etc/rc stuff) which are files in the package, and are appropriately dealt with by utility programs. We don't manually change crontabs, rc scripts, inetd.conf's, etc. It's a *gigantic* maze of stuff, but when you're trying to do software support on 200 or so machines, each with a different administrator, and a different desired selection of software on 9 (count 'em 9) different hardware/os combinations, you seem to need a bunch of rules and a bunch of automation.
jpe@egr.duke.edu (John P. Eisenmenger) (10/20/90)
From article <1990Oct18.054219.11446@watdragon.waterloo.edu>, by jmsellens@watdragon.waterloo.edu (John M. Sellens): > and a different desired selection of software on 9 (count 'em 9) > different hardware/os combinations, you seem to need a bunch of 9 -- big deal. I have to personally deal with 7, #8 is present and there's always the threat of me getting involved, #9 is on the way (within a week or so). The difference is that I have fewer than 40 machines (30 something ;-) ... -John P. Eisenmenger Duke University Dept. of Computer Science Durham, NC 27706
jpe@egr.duke.edu (John P. Eisenmenger) (10/20/90)
From article <1124@cameron.egr.duke.edu>, by jpe@egr.duke.edu (John P. Eisenmenger): > -John P. Eisenmenger > Duke University > Dept. of Computer Science ---------------- I musta had CS on the brain yesterday -- I'm actually in the EE dept... -John