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 3F84D1381F3 for ; Tue, 18 Dec 2012 14:38:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7187421C114; Tue, 18 Dec 2012 14:38:31 +0000 (UTC) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9F4BF21C022 for ; Tue, 18 Dec 2012 14:37:12 +0000 (UTC) Received: by mail-bk0-f49.google.com with SMTP id jm19so376484bkc.36 for ; Tue, 18 Dec 2012 06:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:message-id:in-reply-to:references :organization:x-mailer:mime-version:content-type :content-transfer-encoding; bh=O0/2XTm2yGtJqh71RJ88roSFgOMYL560C9rwq00ffxE=; b=w5haJAOK3bwCDE0lyc3Ub6Vo6u651Y6B1XgVLKc3WpQEUUQABBoSqk8JmtfmBnPxy1 JCbS19BtTC/pQFWa62bbBJNYIrhGOWnOmXBj+w/kFBRvwFKUjjDyoeLd3wOxZirwcE6i /VOD/foGMHJwDWl4Thgrr99riUn1DN0E9j//lrvL3b6c+dCp2X50nBrIZsn0IKEz8m/Y UrMU7K/PCMj/ibNdY3rZ9RA16BoV4y1RvynLfCg3PjeYYYPOfWKf8tfxTE2O9REAUN9L 0YgTx4Wq6O8MWCmWXdkcpYcUWdsD+MctHeHtPieyIoANv6tZqdaJuIA2BXBFoJrUVl0E LUNg== X-Received: by 10.204.153.197 with SMTP id l5mr811098bkw.80.1355841431169; Tue, 18 Dec 2012 06:37:11 -0800 (PST) Received: from khamul.example.com (196-215-209-117.dynamic.isadsl.co.za. [196.215.209.117]) by mx.google.com with ESMTPS id z5sm1515121bkv.11.2012.12.18.06.37.08 (version=SSLv3 cipher=OTHER); Tue, 18 Dec 2012 06:37:09 -0800 (PST) Date: Tue, 18 Dec 2012 16:33:32 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? Message-ID: <20121218163332.7956f31a@khamul.example.com> In-Reply-To: References: <50CB1942.3020900@gmail.com> <50CB4A3C.1030109@gmail.com> <50CB5406.7040404@gmail.com> <8738z7hgsa.fsf@ist.utl.pt> <20121216171043.71084070@khamul.example.com> <20121217104621.735bf43a@khamul.example.com> Organization: Internet Solutions X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.14; x86_64-pc-linux-gnu) 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: b059c144-a50e-4f4d-94ef-78a108380d2e X-Archives-Hash: 42be4c3e95aadb96f42fd1df34db8eb7 On Tue, 18 Dec 2012 09:08:53 -0500 Michael Mol wrote: This sentence summarizes my understanding of your post nicely: > Now, why is /usr special? It's because it contains executable code the > system might require while launching. Now there are only two approaches that could solve that problem: 1. Avoid it entirely 2. Deal with it using any of a variety of bootstrap techniques #1 is handled by policy, whereby any code the system might require while launching is not in /usr. #2 already has a solution, it's called an init*. Other solutions exist but none are as elegant as a throwaway temporary filesystem in RAM. I should be clear that I do not necessarily support Lennart's solutions, but I do support his perception of the problem (at least partially). We cannot support situations where *launch* code is haphazardly scattered in location X and this must always work for all values of X. We already have a remarkably parallel situation in /boot - in order to boot at all, the code running at that point in time needs to be able to find stuff, and it finds it (by policy) in what we will later call /boot. I see this /usr debate as the same thing on a larger scale. -- Alan McKinnon alan.mckinnon@gmail.com