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 6CB9013882C for ; Sun, 3 Feb 2013 17:25:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 21C6721C03F; Sun, 3 Feb 2013 17:25:47 +0000 (UTC) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6BD4B21C01F for ; Sun, 3 Feb 2013 17:25:45 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id 8so4063780wgl.6 for ; Sun, 03 Feb 2013 09:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nUhBilSFhL1sLbYtWcoC/Tu2hMfl7ikTT7YaS4gpfMc=; b=luM9yO+Uv71ABOLn9V0SL9QzhZPVeBHcgRSSJ7E2dxV15m6NvWDA/KmRs4cjPVTFV4 p4nEgwUd4XvcUr4Z/ZkH3PNEPlwkQqG85hMYRDIq9juWCOCdNZdI7P4masTIswtAdT5Q xx4k6pm5/2P54SezpsrLFu1hafJrbwA1fvGUG+WkutjLbP6zsNbBjKkxG4YajUMm4Jvg EsjtY8brJRt0Lm86RQyyOPA1K0NyVBlWgmBek6MXhrBy9Dzuiltdi1CSIhis2Lrfiqed cq4uk0o+zjcYWO2A3ey3IjpTReulhorPKwTgxZqNP0fzS0fqPtrCXcZsTkTYqaNzlLVi z5nA== X-Received: by 10.194.76.237 with SMTP id n13mr31035758wjw.57.1359912344029; Sun, 03 Feb 2013 09:25:44 -0800 (PST) Received: from [172.20.0.41] (196-215-2-98.dynamic.isadsl.co.za. [196.215.2.98]) by mx.google.com with ESMTPS id g2sm16740831wiy.0.2013.02.03.09.25.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 09:25:43 -0800 (PST) Message-ID: <510E9D62.6080500@gmail.com> Date: Sun, 03 Feb 2013 19:24:50 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev-191 bit me. Insufficient ptys 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> <20130203145445.50faece2@digimed.co.uk> In-Reply-To: <20130203145445.50faece2@digimed.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: cfd3697e-7e81-4aa7-91ab-e1057ef98feb X-Archives-Hash: f40631b90ca9ebeb76f48af095e3808f On 03/02/2013 16:54, Neil Bothwick wrote: > 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. OK. So here's what we have. gentoo-dev thrashed this same conversation to death with equally ambiguous results. There too a lot of people were saying "But we shouldn't break user's machines!" And there was vast consensus about that. The next post invariably said something like "We must do !" And the reply to that was almost always "OK hotshot, you covered situation A (coincidentally your situation)> Now, what about valid situations `seq B J` - *all of which are supported*. Please provide a plan for those." And the response to that usually started with "Um..." and didn't actually contain an answer. So I say to you "Neil, what is your solution for all the myriad configurations possible that DO NOT resemble your own? We know what your preferred solution is, as you stated it clearly, but I am interested in all those other users not covered by that. Please provide a well thought out solution that works for them as well as yours would work for you." I'll bet good money you come to the same conclusion I did (based on the conclusions on gentoo-dev):: - trying to infer something from the current running kernel, or /usr/src/linux/.config or some magic name in /boot/ is pointless and leads to so many false positives it isn't worth the effort in the general case. - a console message and an elog generated in one of the *pre hooks is about as good as it gets ... - ... backed up by a news item before the time so forewarned users are forearmed users - the devs did in fact cock up gloriously by omitting all prior notification and learned a bitter lesson - whatever the devs do, this version of udev is going to fuck things up horribly for a lot of people - despite what Lennart and co will whinge after the fact, the real problem lies with udev and it's complete lack of any fallback should DEVTMPFS not be available. This last one is to my mind crucial. Who cares what kind of filesystem /dev is mounted as? It's a filesystem, it's not uber-magic. it's a place where udev can stick it's nodes. If it doesn't have a tmpfs, well then it can wait till / is mounted and write it's stuff there. udev already has a guarantee that /dev will exist as soon as / is mounted, even if /dev is part of / What's this mandatory tmpfs all about anyway? Why is a userspace daemon dictating mandatory kernel behaviour, especially regarding something that, by design (mount points), is supposed to be transparent to everything under the sun moon earth and stars? -- alan.mckinnon@gmail.com