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 51DA01381F3 for ; Tue, 18 Dec 2012 22:56:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6C72D21C05C; Tue, 18 Dec 2012 22:56:25 +0000 (UTC) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9D06621C03E for ; Tue, 18 Dec 2012 22:55:17 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id uo13so1275996obb.22 for ; Tue, 18 Dec 2012 14:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KsTnW0dTK6BiyOyE5LXeTMwu3OFeLvMbAASoaSYDXwU=; b=YH732cBO4QlPjFphAedrqyGsyGD7PQ0dtxMGSh854kSi0Qgm40ULFtV4hHaf697uDT JIR2dB4IWdMfPvDHd4Jc0bFBxjMr7MVVjHQ13QISIusAbUEDJ1EWrNfDk5OHVXwooiWM Kc8eNmK1wCMFHv+m3fhJlfvYm7Dirv0EAnrhU6/QO7tVaKQr8sRuSQc2qbVLdk1cH47i SaW6/pQQsQY0sslvvRkvB9FSQXCAHQCO0V53OLWQQHkRPohzj1tvJjrLieOs8V3k+CnQ zQMzlQKakK4AsGbnMYyO/n+CHps/w5Yic2STTTM9uSH2Bvu+Fb6ZRdx4MnRn5fS3SZFM tUbA== 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 Received: by 10.60.6.226 with SMTP id e2mr3232691oea.56.1355871316826; Tue, 18 Dec 2012 14:55:16 -0800 (PST) Received: by 10.76.20.243 with HTTP; Tue, 18 Dec 2012 14:55:16 -0800 (PST) In-Reply-To: <20121218163332.7956f31a@khamul.example.com> 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> <20121218163332.7956f31a@khamul.example.com> Date: Tue, 18 Dec 2012 17:55:16 -0500 Message-ID: Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 070f8a69-b166-4f4c-bcf7-5941be371475 X-Archives-Hash: e21f258b3491e95623ffb5116fd827d0 On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon wrote: > 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. This is the solution I favor. Systemic structure which allows dependency leakage is indicative (to me) of lack of foresight and proper component role limitation, and ought to be fought. > > #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 find virtually nothing elegant about a temporary filesystem in RAM. It duplicates code that already exists on the system, and it represents and additional maintenance step in system upgrades. It seems almost a given that if someone is keeping multiple kernel images on a system, they're not updating the initr* for each when binaries that would be found in each are upgraded or rebuilt. In Debian, Ubuntu and others, this is handled by a post-install hook where the initr* image is rebuilt. To me, this honestly feels like a hack. In something like Gentoo, I'd rather see package placement driven by whether or not it will be needed to get all mount points mounted. If that means i18n databases under something like /boot/data, that seems reasonable. To me, the only cases where initr* feels like the right solution are things like netboot or booting from read-only media. > > 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. -- :wq