From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1F1RlW-0001oB-Kb for garchives@archives.gentoo.org; Tue, 24 Jan 2006 17:15:35 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k0OHEpDo017336; Tue, 24 Jan 2006 17:14:51 GMT Received: from mail.tar.bz (s175249.ppp.asahi-net.or.jp [220.157.175.249]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k0OHD1rS019275 for <gentoo-dev@lists.gentoo.org>; Tue, 24 Jan 2006 17:13:02 GMT Received: (qmail 14749 invoked by uid 210); 24 Jan 2006 17:13:00 -0000 Received: from 192.168.1.122 by dorf (envelope-from <kalin@thinrope.net>, uid 89) with qmail-scanner-1.25st (clamdscan: 0.87/1096. perlscan: 1.25st. Clear:RC:1(192.168.1.122):. Processed in 0.776938 secs); 24 Jan 2006 17:13:00 -0000 Received: from kpc.tar.bz (HELO ?192.168.1.122?) (kalin.smtp%tar.bz@192.168.1.122) by dorf.tar.bz with ESMTPA; 24 Jan 2006 17:12:59 -0000 Message-ID: <43D66006.4090504@thinrope.net> Date: Wed, 25 Jan 2006 02:12:38 +0900 From: Kalin KOZHUHAROV <kalin@thinrope.net> User-Agent: Mail/News 1.5 (X11/20060115) Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] RFC: emerge snapshots X-Enigmail-Version: 0.94.0.0 OpenPGP: id=26BE7385 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: a2b53a9c-9467-4317-a336-23dbd805d774 X-Archives-Hash: 682dc62036383c144ea18bfe9d35da2e 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@gentoo.org mailing list