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 1QDDmG-0002Q1-3u for garchives@archives.gentoo.org; Fri, 22 Apr 2011 10:39:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C97481C00F; Fri, 22 Apr 2011 10:39:46 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id EE2561C005 for ; Fri, 22 Apr 2011 10:39:16 +0000 (UTC) Received: from shanghai.localnet (p5B213663.dip.t-dialin.net [91.33.54.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: Polynomial-C) by smtp.gentoo.org (Postfix) with ESMTPSA id 93E571B4011; Fri, 22 Apr 2011 10:39:15 +0000 (UTC) From: Lars Wendler To: Donnie Berkholz Subject: Re: [gentoo-dev] openrc portage news item Date: Fri, 22 Apr 2011 12:39:04 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38.3; KDE/4.4.5; x86_64; ; ) Cc: gentoo-dev@lists.gentoo.org, Kfir Lavi , pr@gentoo.org, William Hubbs References: <20110413181538.GA2894@linux1> <20110421011221.GA1736@eee> In-Reply-To: <20110421011221.GA1736@eee> 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; boundary="nextPart3137610.4DvJ0YOLZd"; protocol="application/pgp-signature"; micalg=pgp-sha512 Content-Transfer-Encoding: 7bit Message-Id: <201104221239.11593.polynomial-c@gentoo.org> X-Archives-Salt: X-Archives-Hash: 4d7b1990cb15017aaa42c389b7f667cc --nextPart3137610.4DvJ0YOLZd Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =2D-=20 Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler Am Donnerstag 21 April 2011, 03:12:21 schrieb Donnie Berkholz: > On 13:32 Thu 14 Apr , Kfir Lavi wrote: > > When i run world update, I usually don't really check all the written > > stuff. > >=20 > > If I do this, I'm sure a lot more Gentoo users do the same. So do > > expect people rebooting the machine without checking what your have > > wrote. This can be a major headache if you have few systems that are > > doing auto updates. I would solve this issue by stopping the emerge > > and getting the attention of the user. If I don't get the attention of > > the user, no openrc will be installed. It should be something like > > emerge -C ... 1 .2 3 4 5... > >=20 > > To conclude, you can't issue such a change without proper confirmation > > from the user. >=20 > I know this is the case. You're going to get literally thousands of > people (or more) who break their Gentoo systems if that indeed is the > consequence of not reading the migration guide and doing some action. >=20 > From a glance over the guide, it wasn't immediately obvious what in > there would result in a broken system. Perhaps it's the "run > dispatch-conf" that's buried in the middle of a paragraph without enough > emphasis? That's particularly confusing for people who use etc-update > instead, and it *needs* to move somewhere more obvious like a separate > code listing with big tags and bold text. The line of red > text just isn't enough, it needs to stand out even more. >=20 > 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? I didn't test it intentionally. The last time I accidently rebooted a syste= m=20 freshly moved to bl-2/openrc without updating the config files the boot pro= cess=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 b= oot=20 process with a message similar to "nothing left to do in this runlevel" and= I=20 wasn't able to log into the system. Another problem I've once encountered after updating a system to use openrc= =20 was no running udev daemon after boot. I first didn't notice this but X did= n't=20 start and funny part was that X won't tell you it cannot start because the= =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 migration= =20 guide but it should be explicitly pointed out how fatal this can be to not= =20 have udev getting started. I can offer to "abuse" my two stable VMs (amd64 / x86) for this to test if= =20 there's interest in getting "exact results". :) > One potential cleaner approach to the same idea Kfir suggested is to > make it an interactive emerge with an ACCEPT_LICENSE-like feature that > pops up something you must read and agree to. --nextPart3137610.4DvJ0YOLZd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABCgAGBQJNsVrPAAoJEPiazRVxLXTFYVQQAKJeJ3oycEKlL8zeecOoJJK9 o+1QmKUwTyeex2Xh04qiBfoQ9+jXrQcqqPcUDvLbeYwEYN3gryXbHkdktm7SXe3N YYd80V9/T1QFuoeIbx8C3bJlBbnNvkOpiE2gM7mQQkIJja8tkhDaGyHx3RtmSHVo ygQ2IpH7sAcEvsqmhLLwUHohKM/nxwT/bXAgd0bPjGy6SkL0oju/nFMyg/4vu+Ye cquqZL+rNnogj31EpJq++5nzm3GPbN/krutpsbfzTsvou02Ih5jjMHSnrBJV+EGu 0DGuVGOYmVx60nZuW0r8ngRcqbX1qyKZxN2zQ9QMS9Kb2fiFNGdLaQZfMy5x1s9w O9cHV0fHxnsTKVPkt/USoUv5cEj3kb1Tvs3ZV8VmvVRA8Dqx7qLcx8vasXfhb4ae dfBvLnH65GbPTe5RYxtbyXNPy9Kxo4ngaI+4c6QHj5dIXqauF0xitmAvcRAjrhEg bGdOwanI8iCZ1BV3Uh0EHAf9YSm5ilidXysVfwd2ZjC6ovDZ3cpkQxAaldPAzmLH 3bIvHhzx0ViesxreLgj4YcKZ/fHq+fxjT6L3Qa6rJAy8EZltanyvf/7i+hPwzDjz VKRy4XWuDZtdfQ5s3PEey634RDOxWMRvoH8z+rQd+TNMJWUZTsEmp0QGgzq+cSe5 iwFoInf8Zi0OrH0r1KPo =zCTT -----END PGP SIGNATURE----- --nextPart3137610.4DvJ0YOLZd--