From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 7A330138828 for ; Sun, 3 Feb 2013 14:55:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5838721C069; Sun, 3 Feb 2013 14:54:56 +0000 (UTC) Received: from mail.digimed.co.uk (82-69-83-178.dsl.in-addr.zen.co.uk [82.69.83.178]) by pigeon.gentoo.org (Postfix) with ESMTP id 89A6121C03F for ; Sun, 3 Feb 2013 14:54:54 +0000 (UTC) Received: from digimed.co.uk (shooty.digimed.co.uk [192.168.1.8]) by mail.digimed.co.uk (Postfix) with ESMTPSA id 879A48003C for ; Sun, 3 Feb 2013 14:54:53 +0000 (GMT) Date: Sun, 3 Feb 2013 14:54:45 +0000 From: Neil Bothwick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev-191 bit me. Insufficient ptys Message-ID: <20130203145445.50faece2@digimed.co.uk> In-Reply-To: <510E51DF.3070201@gmail.com> References: <20130202162110.1623aaa5@weird.wonkology.org> <20130202211738.66a72582@khamul.example.com> <20130202203157.0bc3ba12@digimed.co.uk> <510D7B53.3090406@gmail.com> <20130203112416.400b433a@digimed.co.uk> <510E51DF.3070201@gmail.com> Organization: Digital Media Production X-Mailer: Claws Mail 3.9.0cvs60 (GTK+ 2.24.14; x86_64-pc-linux-gnu) X-GPG-Fingerprint: 7260 0F33 97EC 2F1E 7667 FE37 BA6E 1A97 4375 1903 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/CrLo92dFr9ed0FosxLhjLwa"; protocol="application/pgp-signature" X-Archives-Salt: 268b2e8c-f658-48af-977e-c4d9cb354b4d X-Archives-Hash: c1096a4d11b4483df947773e707e9ae3 --Sig_/CrLo92dFr9ed0FosxLhjLwa Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 03 Feb 2013 14:02:39 +0200, Alan McKinnon wrote: > Nor does it make it wrong. I'm all for Gentoo allowing you to shoot > > yourself in the foot, I just think it's a good idea to let you know > > the gun is pointing at your foot before you pull the trigger. > > Updating udev without the correct kernel options WILL break the > > currently running system. =20 >=20 > And that is the problem. >=20 > WHICH kernel config and for WHICH kernel? The ebuild has no way of > knowing and there is no sane mechanism for the user to indicate which > one the ebuild should use. The current kernel, the one it already uses to determine whether to print the warning. All I'm asking is the the warning says "I'm going to break your computer" instead of "I've just broken your computer and let's hope you can fix it before anything causes a reboot". > Any solution you come up with is going to be fraught with difficulties. > Remember that kernel ebuilds are unique, it is the one packages where > nothing is built or put into a runnable state, the ebuild only unpacks > the tarball. So the ebuild cannot know what the config is going to be, > it cannot know what kernel is going to run, it cannot fix any flag > errors it finds, it cannot even know where your sources are or even if > you have a kernel package installed at all. You quite possibly do not > have a /boot/.config and you might not have enabled /proc/config.gz. >=20 > See how deep this goes? Oh yes, and I don't see how it is possible to cover all situations. But if the ebuild can detect that a warning is needed, it should give that warning in time to avoid breakage. =20 > In short, there is absolutely no sane approach the ebuild could follow > to protect you from yourself. This sin;t about protecting the user from themself. They have a perfectly working system which portage then renders unbootable with absolutely no warning > Yes, it might help YOU in YOUR particular > setup, whilst infuriating others who do it differently. There are already ways to skip warnings, like $I_KNOW_WHAT_I_AM_DOING. > Think it through logically, the only thing you are left with that works > is to inform the user of what is found and suggest approaches to take. My criticism is not of that approach, it is of WHEN the warning is given. This isn't about a lack of convenience, this upgrade WILL break a computer that was working beforehand, and not tell the user about it until after the damage is done. I'm not saying it is easy to find a solution that helps avoid breaking while not inconveniencing others, but that is no reason to not try. --=20 Neil Bothwick IBM - Incredibly Bastardized Multitasking... --Sig_/CrLo92dFr9ed0FosxLhjLwa Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEOejwACgkQum4al0N1GQMHZQCeNWtGoZFdglJtLLjvAqGaqbZr u/UAn1fpYFUZxvWtK1iue2otAhJUCbqN =yQDn -----END PGP SIGNATURE----- --Sig_/CrLo92dFr9ed0FosxLhjLwa--