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 1QFseX-00011r-AU for garchives@archives.gentoo.org; Fri, 29 Apr 2011 18:42:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 04A461C06A; Fri, 29 Apr 2011 18:42:33 +0000 (UTC) Received: from mail-pw0-f53.google.com (mail-pw0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 7D3E11C06A for ; Fri, 29 Apr 2011 18:41:34 +0000 (UTC) Received: by pwj7 with SMTP id 7so2893983pwj.40 for ; Fri, 29 Apr 2011 11:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=BVVfu+Mm4ofKTeB8dhHVlxvR+pxN3P6vJJYO6zI0+uw=; b=MtvpAe3kiQtKnKH6hUyTYdSFe3syKfjhA6C/zLDBnA+mrUHXdfgas8O50rz4kTrE8N l0qWb7K8Ga+HvXIVZXkjls4fevE2oBTiDipbMsmqc4cBaD2nZw2o4FwqyOgqNwLHwBnP /Znc0LRnKHZBVvViJTSqKUta/tE9Op+1uBU4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=uFdUnH5oQnWIt7UHS1k2JPIAhCasWwPPtCud15Y+4ptItcvZ90h/GyI3PYi4N5+nQs bEWDbXe8Reu02p0tzuS1DOX1NB2xIkDadnLCFuQWXBWCqNt6nQddQzVl7I3AGIRfBkJW pAvsN4JOCkXj7xYR67DAHgeTiDvWC5EK9oBKg= Received: by 10.68.15.134 with SMTP id x6mr5474198pbc.308.1304102493776; Fri, 29 Apr 2011 11:41:33 -0700 (PDT) Received: from smtp.gmail.com (c-24-20-36-83.hsd1.wa.comcast.net [24.20.36.83]) by mx.google.com with ESMTPS id 8sm2066822pbw.23.2011.04.29.11.41.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2011 11:41:32 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Fri, 29 Apr 2011 11:41:29 -0700 Date: Fri, 29 Apr 2011 11:41:35 -0700 From: Brian Harring To: William Hubbs Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] openrc portage news item Message-ID: <20110429184135.GA20648@hrair> References: <20110413181538.GA2894@linux1> <20110421011221.GA1736@eee> <201104221239.11593.polynomial-c@gentoo.org> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <201104221239.11593.polynomial-c@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: X-Archives-Hash: 49444ba7ad35e5e6434f79a3f8584474 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2011 at 12:39:04PM +0200, Lars Wendler wrote: > Am Donnerstag 21 April 2011, 03:12:21 schrieb Donnie Berkholz: > > It seems like nobody's really clear on what exactly happens though, > > since I've seen people talking about this *maybe* resulting in an > > unbootable system. Has anyone tested it? >=20 > I didn't test it intentionally. The last time I accidently rebooted a sys= tem=20 > freshly moved to bl-2/openrc without updating the config files the boot p= rocess=20 > threw a couple of strange errors. I cannot exactly remember what kind of= =20 > errors that were but the result was a system hanging in the middle of the= boot=20 > process with a message similar to "nothing left to do in this runlevel" a= nd I=20 > wasn't able to log into the system. > Another problem I've once encountered after updating a system to use open= rc=20 > was no running udev daemon after boot. I first didn't notice this but X d= idn't=20 > start and funny part was that X won't tell you it cannot start because th= e=20 > devicenodes in /dev for the graphics card were missing. So took me nearly= a=20 > day of frustrating research until I found that the udev init script wasn'= t=20 > added to the sysinit runlevel. Of course this is mentioned in the migrati= on=20 > guide but it should be explicitly pointed out how fatal this can be to no= t=20 > have udev getting started. >=20 > I can offer to "abuse" my two stable VMs (amd64 / x86) for this to test i= f=20 > there's interest in getting "exact results". :) Exact results please; the pkg_pretend crap proposed elsewhere (which=20 is yet another way to crap up stage builds) frankly sucks. Mind you I'm just looking in, but this whole upgrade process really=20 reads fairly suboptimal to me. It's definitely possible that this is=20 the best that can be done, but I'd like to see exactly which issues we=20 can't resolve in some fashion via pkg_postinst tricks w/in openrc. I'd much rather have an ebuild that violates a few rules than forced=20 "you must accept this beyond normal mechanisms" and potential "can't=20 boot" upgrade processes. So... details please, and why we can't script our way past chunks of=20 this. :) ~brian --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAk27Bl8ACgkQsiLx3HvNzgfs1QCfQV2TB8fYoSsKhA3xz9IL1ldy Z9cAn37/qd/Mwqaq2DDY98E5NFlRAFgf =N//U -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND--