From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QG4Od-0001ng-1H for garchives@archives.gentoo.org; Sat, 30 Apr 2011 07:15:19 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 10EA01C02F; Sat, 30 Apr 2011 07:15:03 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A8A861C00E for ; Sat, 30 Apr 2011 07:14:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 3C84F1B402B for ; Sat, 30 Apr 2011 07:14:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 required=5.5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNSgd-xN5Lhh for ; Sat, 30 Apr 2011 07:14:18 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id AA49C1B4007 for ; Sat, 30 Apr 2011 07:14:16 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QG4NW-0005Bi-RV for gentoo-dev@gentoo.org; Sat, 30 Apr 2011 09:14:10 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Apr 2011 09:14:10 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Apr 2011 09:14:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: openrc portage news item Date: Sat, 30 Apr 2011 07:13:59 +0000 (UTC) Message-ID: References: <20110413181538.GA2894@linux1> <20110421011221.GA1736@eee> <201104221239.11593.polynomial-c@gentoo.org> <20110429184135.GA20648@hrair> <20110430021950.GC6032@linux1> <20110430045945.GB20648@hrair> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.134 (Wait for Me; GIT 9383aac branch-testing) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 56a2371861684737f8a75508d6c166d1 Brian Harring posted on Fri, 29 Apr 2011 21:59:45 -0700 as excerpted: > Checking the boot levels, udev included, same thing- if ROOT=3D/ and > baselayout is there already you likely *could* look at the running > system to see what's needed/in use, and kick rc-update as needed for > spots where it *isn't*. Um... 32-bit chroots for amd64 comes to mind, tho that's just a single=20 supported case of the general idea. Here, I've adapted the idea slightly= =20 by simply installing a complete system to the chroot, just never actually= =20 /running/ it from there, as a maintained system image that was initially=20 transferred to USB, now updated thru rsync, for my netbook. Portage's ROOT is unchanged in these cases, but depending on how the=20 detection of the running system is achieved, the script might attempt=20 changes based on the components of the 64-bit HOST system, not the 32-bit= =20 chroot system image, or conversely, changes inappropriate for an image=20 that never actually boots on its host system. That would *NOT* be a good= =20 thing! So any such detection would have to be based on far more than the setting= =20 for ROOT and existence of baselayout. Meanwhile, all this is a rather nice idea in theory, but with literally=20 days left before pulling the trigger, now's rather late in the game to=20 bring the suggestion. Development and proper testing of such a script=20 would certainly take months, at least. This whole idea, suggested now,=20 seems to me to be a rather advanced case of letting the perfect be the=20 enemy of the far better but nobody claiming perfect. The time for such a= =20 suggestion would have been several months ago when the final push toward=20 stabilization and development of the final migration technique was=20 announced. And certainly, trying to shove the required development and=20 testing into anything less something like six more months reasonable=20 minimum, is folly indeed. Meanwhile, existing stable gets further and=20 further behind and harder to maintain, and Gentoo looks more and more=20 "legacy". Are you actually trying to delay the upgrade to OpenRC /forever/? Why? =20 There's other questions I could ask but there ARE things worse than=20 unasked questions. I'm seriously fighting the urge to go there as that=20 bit of list history is something that doesn't need repeated, for sure. Meanwhile, Gentoo has always been about expecting Gentoo's users to take=20 responsibility as their own sysadmins. Yes, we document, and automate=20 where reasonably possible, but there's a reason for etc-update, dispatch- conf, etc. This is as good a case for letting Gentoo users take ultimate= =20 responsibility as admins on their own systems as it gets. We've waited=20 long enough. The guides are ready. The systems are ready. The warnings= =20 are ready. Now it's time to pull that trigger. --=20 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