From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-145009-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 6CB9013882C
for <garchives@archives.gentoo.org>; 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 <gentoo-user@lists.gentoo.org>; Sun, 3 Feb 2013 17:25:45 +0000 (UTC)
Received: by mail-wg0-f51.google.com with SMTP id 8so4063780wgl.6
for <gentoo-user@lists.gentoo.org>; 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 <alan.mckinnon@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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: <CA+czFiD0PYZ7tDr_zbq0gYeLPPp-MrTsjL4ahJL0yCr1h1bYfg@mail.gmail.com> <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 <insert current poster's bright idea here>!"
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