From: Anders Johansson
Every user has customized her or his installation. Lots of rpm's for specialized applications install to /usr and not /usr/local.
Then the rpms are broken. The LSB clearly says that locally installed software should go in /usr/local. That tree is guaranteed not to be touched by upgrades. The upgrade procedure can do more or less what it likes to the rest of the /usr tree. Anders A problem is that what's "locally installed" is not something that any single vendor controls. If a user grabs the latest version of GodzillaEatsSpam.rpm from the web, he or she will usually find it to be non-relocatable, won't (or can't) go beyond installation defaults to take the trouble of moving to /usr/local. Surely a vendor is not responsible for upgrading what's in /usr/local. I don't suggest that. But neither should installation of a new release require deleting GodzillaEatsSpam if it's in /usr: tarring to tape the fs, then doing clean install, then selectively untarring takes forever. Am I wrong in thinking that, when the upgrade encounters /usr/bin/GodzillaEatsSpam, it (conceptually) asks: 0. Am I working interactively? y/n 1. Am I instructed to upgrade GodzillaEatsSpam? If yes, continue. If no... 2. ...Is GodzillaEatsSpam in the rpm database? If no, continue. If yes... 3. ...Am I about to annihilate files which GodzillaEatsSpam needs? If no, continue. If yes... 4. If I'm working interactively, warn user about imminent annihilation and ask instructions. (My own effort to upgrade from 7.3 -> 8.0 didn't get that far, but that's another set of issues.) jim bennett