[gentoo-dev] RFC: emerge snapshots

[Kalin KOZHUHAROV]

Hi all.

During the last many months, more than once an idea occured in my mind, so I
decided to share it.


2006-01-25T01:34 kalin $ dd if=/dev/brain of=gentoo-dev bs=1 count=3292

Do you think it will be good to have something like a snapshot of the
installed packages?
Something that will help when something unexpectedly breaks and you cannot
fix it bu shuffling around its dependencies.

Because s--t does happen; sometimes.

Right now vmware-workstaion is broken and I am failing to understand why for
the last few hours. But that is just an example, forget about it.

So how can we get that thing? Let's call it "emerge snapshot" not to be
confused with portage snapshots used during install.

One way is to employ a version control system, say subversion, to keep the
list of installed packages. It has to be updated during emerge.
Also there should be a way to insert markers like "OK, tested and working",
"going to try this fuzzy foo install, mark!" All these should be timestamped.

So after the "_BANG_ my box is b0rked", it will be easy to retrace your
steps by just doing `emerge --log 3` to see the last three labels/log entries:

3544	2006-01-01T12:12	OK, tested and working
3545	2006-01-01T12:12	going to try this fuzzy foo install, mark
3546	2006-01-01T12:12	yay, new modular X is in ~arch (-:

then `emerge --revert -r3544` and everything is smooth and runnig again.

The "behind the scenes" actions to be taken by portage is to unmerge
everything that was merged after -r3544

That was the easy part.

Now what if some config file is b0rked?

Solution 0 (slow, disk space):

_before_ upgrading a package, or even before installing the same package in
a new SLOT, do `quickpkg $PACKAGE`

Solution 1 (better): Anybody?


Some notes to consider:

AFAIK, at present portage leaves most (all?) files that are in
CONFIG_PROTECT on unmerge... is there any easy way to trace which files are
left over in the system and delete them? Parsing the logs might help, but
unless it is automated it will be error prone and cumbersome.

Now imagine this timeline:
r100
emerge foo
r101
emerge --unmerge foo
r102

Is there anything else to be taken care so that the system @r100 and @102 is
the same? (sans system logs, user created files and the like)

I guess all the tools and info are already in portage and by writing a bunch
of scripts (to parse the logs mainly) it will be feasible to make it work.
But if it is automated, this will give _HUGE_ advantages:

1. Users will be instructed to revert to a good point when something breaks.
Probably an automated reporter can be hacked up

2. Bugs can easily be confirmed if there is enough CPU power
(Give me your broken "emerge snapshot" and the one before that)

3. devs and trying-to-be-devs, testers will be able to test easily if
package foo-2.3.4 does break something without the need of things like
vmware (snapshots)

4. Any n00b will have the "Ctrl+Z", "Recycle bin", "Trash bin", ":undo"
whatever to their whole system

5. (dangerous) Experimenting on semi-production servers will be easy!

6. Given the above 5, Gentoo user base will grow enourmously:

"You have the flexibility, now you have stability. No need to dream, welcome
to reality: it's called Gentoo!" (from the 2006.3 release campaign :-)

I know it is far from a GLEP, but let me first see how people feel about it.
Even if not implemented as a whole (at first) it will greatly improve our
Gentoo life.

Any comments? It is an RFC after all :-)

2006-01-25T02:07 kalin $
-- 
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
-- 
gentoo-dev@g.o mailing list