----- Original Message ----- From: "David A. Cobb" <[EMAIL PROTECTED]> > > I've thought about suggesting the same thing but the problem with that > > scenario is that if you cancel an installation, then all sorts of stuff > > is uninstalled -- which probably isn't what you expected. > > Probably not. But "cancel" at what point in the process? It's *real* > hard to program an installation procedure that's robust in the face of a > user clicking the "cancel" button in the middle. Even the > "professional" packages are likely to barf.
It's trivial to design. You treat an install like a series of transactions. You make the transactions as small as you can while satisfing all the system constraints - dependencies etc. Once we've got per version dependencies and conflicts, and ordered package actions (already described in this list) all we need to do is make transactions that begin when a _current_ dependency/conflict is being affected and finish when the system again has a consistent set of dependencies and conflicts. Additionally each package install/remove gets treated as an independent transaction, to allow detection of in-use files. Easy to code? Maybe not. Not too hard either. Replacing open files? Sure. Already designed and proof-of-concept shown for setup.exe. How many to queue at once? Until there are no in-process transactions. The only restriction this puts on the setup process is that post install scripts _must_ be able to be deferred until all the physical file copying is complete. Rob
