jwp@chem.ucsd.edu (John Pierce) (03/30/88)
Yeah, this is an annoying subject.... But I have some sympathy for vendors, too. Mostly they've got to design this sort of thing for people who have no idea whatever about what they're doing. We finally decided to put in the effort to write scripts that save everything we really care about someplace where it's easy for us to get it back. Life's been a lot simpler since then. Sure, the vendor's going to change it on you. Just put back the old binaries (it's very unlikely they won't run) and recompile as you get the chance. It only requires a little thought, and the occassional screw up, to make this relatively less painful than griping about what the vendor did to you. They don't have a chance in hell of figuring out everything you may have changed. -- John Pierce Chemistry Dept, B-032, UC San Diego Internet: jwp@chem.ucsd.edu UC San Diego, La Jolla, CA 92093 Bitnet: jwpierce@ucsd +1 619 534 0203
rsalz@bbn.com (Rich Salz) (03/31/88)
When a release is sent out, the vendor should include a file that lists the stat(2) information and a checksum of every file. The first part of upgrading a new release is to compare this file with the current state of the system. That way, if the checksum of /etc/rc.local is not what was originally shipped, you can at least warn the sysadmin. I wrote such a program once, and the company used it all the time. It's not hard, even when you're selective (e.g., "do a stat of everything in /rel1.2/xy/include except /rel1.2/xy/include/sys, and assume the destination is /xy/include"). In fact, I recall that the UniSoft port of SystemV had something like this. One tricky part is proper updating of the file for maintenance releases. It's almost always a mistake to blindly wipe out entire directories, rather than inserting new files. And requiring people to repartition their disks shows a real lack of foresight on the vendor's part. I remember being real pleasantly surprised by how nicely most upgrades from mt. Xinu and Pyramid were handled. This is an interesting discussion, but it's not really about sources; where should it go? /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.