Fitzcarraldo wrote:RPM used to have a package rollback feature: see the May 2004 Linux Journal article Transactions and Rollback with RPM. The only trouble was: it didn't always work (see e.g. Qs on RPM Rollbacks) and was subsequently dropped. If it was simple to do, all the package managers would do it.
If the major Linux distributions, with all their resources (including many paid developers), cannot produce a reliable package rollback function, then it can't be in the least bit easy.
I think a more viable solution in the case of Linux is the use of a file system that supports snapshots. When Btrfs finally replaces ext4 as the main Linux file system this could become a possibility, providing the creation and restoration of snapshots can be made simple enough for the average user to perform.
It seems that it's not the idea that's unreliable so much as poor packages that may execute scripts that change files. A rollback mechanism for entropy doesn't need to be 100% foolproof in order to be a blessing and potential disaster-averter. A mechanism to compensate for this would be something I've already seen done in Windows... scan the system file areas and the home directory (or registry as the Windows program worked), install package, rescan and see which files have changed. Still probably not 100% foolproof, but again, it's not complex and already being done today (think Intrusion Detection Systems like Samhain). Afick is a small utility that can find new/changed/deleted files.
Sometimes it's not that things can't be done as simply that no one wants to do them or they have higher/different priorities. For instance, openSUSE on ARM - not only have other distros ported to ARM, openSUSE's build service is capable of compiling all of openSUSE for ARM now. However, there's the work of fixing packages that assume only x86 or need patches and applying the patches that probably already exist for the Fedora/Debian ARM ports. It was talked about since 2009 and some work was done, but there's just really no one (with ARM knowledge) interested in going the last mile to polish and test an ARM port, so it still doesn't exist even though it would be easier than other distros to port thanks to the build service.
Fitzcarraldo I remember you were the only one who took my ideas for rollback seriously when I (pleadingly
) brought them up the first time. At that time rather than recommending btrfs you told me all about the NILFS filesystem instead. 
It's a great idea and the best method as long as you can do partial rollbacks (rolling back system files but not data). Unfortunately neither of these filesystems are solid enough for reliable deployment today.What about something like rsnapshot?
http://rsnapshot.org
... I believe this just needs a combination of existing technology/tools and a bit of cleverness. A rollback that's even 80% effective would be more than welcome when the system's unrecoverable by normal means (no backup exists, etc.)
USE AT YOUR OWN RISK: MAY NOT WORK OR EVEN BREAK the backup (
