On Fri, 2007-02-23 at 14:22 -0500, Ric Moore wrote: > > I think it might be wise to consider the old Caldera notion of > using /opt to contain all the goodies that you post install and wish to > be left alone. Then you merely fresh install the core apps while > leaving /opt (and /home /root) alone. It's worth a thought. Ric /opt should really only be used for self contained bundles. IE you could put something like TeXLive in /opt (and many universities do just that) or Java in /opt etc. Often it is /opt/vendor/product/version - so that multiple *self contained* versions can be parallel installed. If packages in /opt are installed by rpm then they need to use an rpm database located on /opt that is not the system rpm database - at which point, the benefits of using rpm pretty much disappear. A tarball with an md5sum list is then more practical. What would be *nice* would be if you could say - rpm database A is system database. rpm database B is /opt database. Packages in B can have their dependencies filled by A but packages installed in A can NOT have their dependencies filled by packages in B. packages in B can not install files outside of /opt Configuration option - packages in B can not install suid root binaries (that's actually easy, both the outside of /opt and suid issue - make /opt owned by a non root user that owns the rpm database and uses rpm to install into that database - then the OS refuses to install suid root files) All that needs to happen for that to work now is rpm needs to be able to check for dependency satisfaction in a database other than the target database. I suppose library paths would be an issue for .so files - and the users path would be an issue as well.