From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j4GAOXSa026160 for ; Mon, 16 May 2005 10:24:34 GMT Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by smtp.gentoo.org with esmtp (Exim 4.43) id 1DXcm6-0004LS-HJ for gentoo-dev@lists.gentoo.org; Mon, 16 May 2005 10:24:38 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DXcld-0001Cn-0v for gentoo-dev@gentoo.org; Mon, 16 May 2005 12:24:09 +0200 Received: from ip68-230-66-193.ph.ph.cox.net ([68.230.66.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 May 2005 12:24:09 +0200 Received: from 1i5t5.duncan by ip68-230-66-193.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 May 2005 12:24:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: i have an idea ! (erescue) Date: Mon, 16 May 2005 03:24:21 -0700 Organization: Sometimes Message-ID: References: <200505151718.06501.vapier@gentoo.org> <4287CE08.3080907@gentoo.org> <20050515234110.GA7844@goliath.roninds.net> <200505151812.14013.electronerd@monolith3d.com> <20050516015654.GA7890@goliath.hsd1.oh.comcast.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-66-193.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: 2bc10803-7de5-41dd-ad0a-aa5b5038070d X-Archives-Hash: 01a2c52a5a7a2eaf0eeb9e56f1770f6d David Stanek posted <20050516015654.GA7890@goliath.hsd1.oh.comcast.net>, excerpted below, on Sun, 15 May 2005 21:56:54 -0400: > On Sun, May 15, 2005 at 06:12:13PM -0700, John Myers wrote: >> On Sunday 15 May 2005 16:41, david stanek wrote: >> > Add an option to emerge, --backup or something similar, that will >> > automatically run quickpkg. >> >> If you set FEATURES="buildpkg", portage automatically makes binary >> packages for you. No need to add new support. > > That would build a binary package for the potentially broken package. > What it would need to do is build a binary package of the existing > merged package. So a user can recover from a botched upgrade. I think Myers' point was that if "buildpkg" is set, the system soon builds up a history of /multiple/ versions back of any particular package. Thus, if any new emerge or remerge borks the system (hmm, interesting term, that, particularly at this moment, but then, this isn't supposed to be a political list so enough of that, just a nod to the heritage...), it's normally fairly easy to quickly recover to a fully working system by just emerging the binpkg, going back as necessary to a known working version, taking a step back if it was a remerge and you just borked the previously working current version. That of course brings me to /my/ point, that buildpkg is a very useful thing to have, certainly with toolchain packages, even if the system is space or otherwise limited enough that it's not a desirable option overall. Thus, my suggestion. Why not create a second feature, toolchain-buildpkg, I'm calling it here for purposes of developing the suggestion, that's on by default, as contrasted to the normal buildpkg being off by default. The Gentoo Handbook would then of course be modified to cover it and mention why Gentoo recommends that it stay on. Portage would then always buildpkg anything rescue-critical, including portage itself, gcc, binutils, coreutils, python, etc. Don't forget glibc (which would of course need put in place from a LiveCD, one's "emergency" copy of the root partition, etc). As mentioned here, tar and bzip2 would be special cases, because while one can untar a package directly over the current filesystem if portage (or python) itself breaks, without tar and bzip2, one is somewhat hosed unless one uses the resources of a backup rootfs or liveCD. Perhaps building them static by default would be a good idea, as well as including them in the toolchain-buildpkg list. With such a feature, and with it on by default, another make.conf parameter would then be useful as well. Call it binver-depth, and set binver-depth=3 in make.globals. Then, when three versions of the binpkg are reached, it would delete the oldest one as it created a new one, thus leaving two presumably known working backups at all times, even if the newest version it just created fails. 0 would special-case to unlimited, of course, since we already have the feature as a toggle. As a bonus, one could then make the normal buildpkg feature follow binver-depth as well, since the code would already be there, or create two separate binver-depth vars so users can control toolchain binver-depth separately from normal binver-depth, if desired. I believe this solution has the merit of requiring the least new code, since we already have the normal buildpkg feature in place and tested. The only new code would be that to control the toolchain package option separate from the others, which should be easy to add, and the rotate functionality (or make it a cron script similar to logrotate), which would be nice but isn't an absolute "must". Optionally, we could simply change the default of the buildpkg feature to "on", along with appropriate coverage in the usual places (GWN, the forums and user list, the Gentoo home page, and naturally, the Gentoo Handbook, for new users). That wouldn't require /any/ new portage code, altho again, a binpkg-rotate cron script would be rather useful. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list