This is an idea I've been working on for a little while. In short, it adds a couple of new features to emerge, specifically:
emerge undo - undo last emerge action
emerge restore [date] - restore installed software to as it was on date X
emerge checkpoint - update installed software list after manually using ebuild as opposed to emerge
where [date] is either:
(a) a number, e.g. "5" = undo last 5 emerges
(b) a date, e.g. "2004/02/01-12:11:29"
(c) a relative time, e.g. "2d" = 2 days ago
stimpy pym # emerge -p undo
Restoring from 2004/02/01-19:25:30
>>> These are the packages that I would merge, in order:
[ebuild UD] app-portage/gentoolkit-0.1.38 [0.2.0_pre5]
Package flags, binaries, package renames etc are all handled correctly. It's been well tested over a year or so. For the last six months it's been solid.
Steps to Reproduce:
The relevant patches are at:
Both /usr/lib/portage/pym/portage.py and /usr/lib/portage/bin/emerge need
patching. Patches are against 2.0.50_pre21.
*** Bug 2042 has been marked as a duplicate of this bug. ***
You may need to rengenerate /usr/lib/portage/pym/portage.pyc (or emerge will crash). This is done by first patching, and then:
python -c "import portage"
Patches against 2.0.50 are at http://www.cs.swan.ac.uk/~csdave/portage/
*** Bug 85146 has been marked as a duplicate of this bug. ***
I think it would be nice since with emerge -uD world, often many package are emerged, the user could specify the package to undo.
for example, I installed recently with emerge -uD world a buggy graphics driver by nvidia. I only needed the old driver back, but had not noticed it's version number. It would be good if I could type
emerge --undo package
and the last installed package is re emerged.
Also an emerge --undo D package
that re emerges all older librarys which new versions would not work because of the re- emerge of the old version of "package"
It already has this exact functionality :-)
Just use emerge --undo [list of packages or regexes]
emerge --undo .*nvidia.*
Unfortunately as can be seen by the version of the patch, I haven't updated this for some time, and probably won't as no-one seems really interested in putting it into main-line portage. But it should be easy to get it up to date again.
Putting a hold on feature requests for portage as they are drowning out the
bugs. Most of these features should be available in the next major version of
portage. But for the time being, they are just drowning out the major bugs and
delaying the next version's progress.
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can
be reopened. Sorry, I'm just not good enough with bugzilla. ;)
*** Bug 111079 has been marked as a duplicate of this bug. ***
*** Bug 143113 has been marked as a duplicate of this bug. ***
Reopening for duping.
Actually this isn't a dupe of 127797
I think this kind of functionality is best handled via filesystem-level snapshots, like btrfs supports via subvolume snapshots. I'm not so sure it would be a good idea for portage to be aware of such things, since it's easy enough for the user to manage with the tools of his/her choice.
*** Bug 654586 has been marked as a duplicate of this bug. ***
There is also defaulting to building binpkgs, and restoring an unmerged pkg from it. That won't track any manual config changes though.
We can create a gentoo-ostree, like https://github.com/coreos/rpm-ostree, but for gentoo.