i don't know of a module but have worked with large cross-platform upgrade scripts in perl, wrapped in a shell script. Anyway, the point i was going to make is that you cannot guarantee that any undo step will do the right thing, depending on the many variables involved on a server environment. in unforseen circumstances, any automated undo can wreak more havoc. the upgrade scripts i worked with had lots of sanity checking and logging of every step in a separate logging directory. in fact the upgrade could run from a separate mount point or drive, so it used as little space in main system as possible. anyway, the upgrade script had milestones for groups of smaller steps, and the script "knew" which small steps were just logged as upgrade log warnings or contributed to milestone failing and upgrade stopped. the upgrade could pick up from where it left off, as long as it was a milestone...so any human operator intervention could concentrate on either undoing or finalising a few small steps, by hand.
in reply to Poor man's transaction construct
the kind of sanity checking and defensive programming would include such things as: if you're creating a database, try to connect and do a fake select that doesn't require a table, and or use return codes from db when executing the statement, making sure to specify username/password and admin level connect style. for creating tables, you can populate one row of the table with well chosen fake data, and make sure you can read it back and insert values match returned values. the upgrade log showed had a timestamp for each step starting and ending, and also included the information returned from any of the rigorous sanity checking, in unadulturated form returned from DB or OS etc. this allowed the upgrade operator to pinpoint fairly well exactly where things fell over.
the hardest line to type correctly is: stty erase ^H