I just spent the last few hours dealing with the "little libpng bug" that pretty much disabled Gnome. As I write, I'm recompiling a lot of things... Anyway, the problems could have been avoided using a commit/rollback scheme. Consider: make a new "root" at /var/rollback/. When the user emerges a package, every clobbered file should be moved into the root at /var/rollback/, and the action logged in a file (like /var/rollback_log). Then if the user finds that his new build has trashed something (like libpng did) he/she could rollback the old system by some command like "emerge rollback". If the user was satisfied, "emerge commit" could wipe the rollback directory to save space. "emerge rollback" would have to read the rollback script and unmerge listed packages (in reverse order). After every unmerge, files may have to be restored from the rollback directory. There's also the difficulty where a file is clobbered twice. Perhaps we would need multiple rollback dirs (/var/rollback000, /var/rollback001). Okay, this is a really big feature request. What do you developers think?
I think this would not be /that/ hard if we were to save the clobbered files by package, in the package. Something like (save the actual files with the overwriting package) /var/db/pkg/foo-4.5/clobbered/bar-1.2.3/usr/bin/bar /var/db/pkg/foo-4.5/clobbered/fletch-2.3/usr/lib/fletch /var/db/pkg/bar-1.2.3/clobbered/ni-7.0/lib/libni.7.so or (save the clobbered files with the package, keep CONTENTS-type files of clobbered files, with an extra field explaining the package it came from. This is probably easier to parse by tools) /var/db/pkg/foo-4.5/OVERWRITTEN contains: bar-1.2.3 /usr/bin/bar ... fletch-2.3 /usr/lib/fletch ... /var/db/pkg/bar-1.2.3/clobbered/usr/bin/bar /var/db/pkg/fletch-2.3/clobbered/usr/lib/fletch ... That way, you can roll back all the way to the original package. If you unmerge a package, it will remove the clobbered files as well, and reassign files that were clobbered by it or move them back into the filesystem. The only problem that I see are files that don't belong to the package, and therefore either were made by the user or made on the fly. But they could just be overwritten as they are now, with config protection like now. Or else they could be assigned to the package that owns the directory that they are in.
Seems to me that this is somewhat provided by the PKG creation option of Gentoo. If you let Gentoo create a tbz2 for each package you install, then "rolling back" would be easy: install the tbz2 for the previous version of libpng. I could see portage creating a tbz2 automaticly before unmerging the package (although in that case it might not include all the original files anymore), and keeping those tbz2 based on some criteria (e.g. last 3 unmerges, disk space, number of tbz2s, etc.). But this provides no guarantee that the tbz2 will be around by the time you figure out something it broken.
i think there also needs to be provision for the concept of a system snapshot. it would be extremely handy to save a snapshot of the system state before doing a harmful/cluttering emerge. if you don't like it, there is no need to reinstall to be 100% sure of the system state, just rollback. no need to get too intricate though, and reimplement a version control system. a single snapshot of current state and a journal+supporting data to be able to rollback to snapshot would do fine. hmm. this could even be implemented with a VCS as the backend? not sure :)
I'm interested in this feature. We can back up files that would be overwrote or removed before qmerge/unmerge. Then if there are any problems, we can restore using the files. Of course, this feature should be option. carpaski: What do you think? If you say 'go ahead', I'll implement it. Thanks
*** This bug has been marked as a duplicate of 40127 ***
