From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.77) (envelope-from ) id 1SrYxQ-00077E-Fv for garchives@archives.gentoo.org; Wed, 18 Jul 2012 18:26:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 70F1AE0655; Wed, 18 Jul 2012 18:26:26 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id AE549E0552 for ; Wed, 18 Jul 2012 18:25:52 +0000 (UTC) Received: by bkwj4 with SMTP id j4so1717654bkw.40 for ; Wed, 18 Jul 2012 11:25:51 -0700 (PDT) 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:content-transfer-encoding; bh=GGSvv70qY07kl6vLx4L+FHY+o3GNHK35RJ9sdoref8Q=; b=VnaacC+uFxPPOgCZMPLAxdBgyJ4Sw5JqfkJc6XAY9+EJrhHFD8HqyVFXgkf+FSSBPR oRuGxRJZ/0nbnxQwkFJ4DhBt5VtgzNawKpe1jAOt2FQPl0ydZYgpdEH0hrOOBfTuxWLz dsBSJzUTq+oYoj4/BpTlVcOg0oI55OqKmsmIS1EkDnJ+GMkOq53Yp+tCCtU4UgthZb0M pUFYZrs6PfVlRilwPQsxtlisFVOLZ6vRY6mAKh+w1/exr0Rcm/LgBMLk2lR++UD75nFQ ZA9Tqb3lAjZ8b13XX5g3mkAQTC5sfMCozKOYs95m5UlBLh1LZETo524bFJiBCUsHK5wQ 8KBw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.129.14 with SMTP id m14mr2356322bks.7.1342635951795; Wed, 18 Jul 2012 11:25:51 -0700 (PDT) Received: by 10.204.10.12 with HTTP; Wed, 18 Jul 2012 11:25:51 -0700 (PDT) In-Reply-To: <20120718195809.242f7d99@pomiocik.lan> References: <5005D70D.3060108@gentoo.org> <1342566449.18313.38.camel@TesterTop4> <50063368.8080106@gentoo.org> <20120718101027.55dd00fe@pomiocik.lan> <5006B7A4.6010202@gentoo.org> <20120718161351.GA19044@serenity.o.westcall.spb.ru> <20120718184012.12446404@googlemail.com> <20120718195809.242f7d99@pomiocik.lan> Date: Wed, 18 Jul 2012 14:25:51 -0400 Message-ID: Subject: Re: [gentoo-dev] Opinion against /usr merge From: Michael Mol To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 288c618c-581e-434d-a111-44622149e12c X-Archives-Hash: 1e3eda01ba58bf619026e10b8ca0be64 On Wed, Jul 18, 2012 at 1:58 PM, Micha=C5=82 G=C3=B3rny = wrote: > On Wed, 18 Jul 2012 18:40:12 +0100 > Ciaran McCreesh wrote: > >> On Wed, 18 Jul 2012 12:35:58 -0500 >> Canek Pel=C3=A1ez Vald=C3=A9s wrote: >> > All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin >> > separated are really instances of the Chewbacca defense [1]. They >> > just don't make any sense. >> >> All the arguments for changing things are just realising that the >> horse has fled the barn and then trying to rationalise not needing a >> horse. > > I believe I don't need a horse. I don't even have a barn either. To carry the analogy, udev forcing a /usr merge is much like "We don't need a horse, so we don't think anyone else should have one, either. If they need a horse, they can use one of those newfangled tractors." Personally, I think the original reasoning behind udev's move was flawed. When I read it, it sounded like "we can't control whether or not anyone else puts boot-required packages into /usr before /usr has been mounted. In order to cover for those packages, we'll force the issue by putting ourselves there." I think that any package which puts boot-required things into a path which may not be available at boot time is inherently broken, and needs to be fixed. There's absolutely nothing about the move which both accounts for boot-required packages requiring access to /var _and_ a sysadmin's need to have /var as a special mount point. To me, it looks a lot like what once was / is now expected to be an initramfs, which I find extraordinarily problematic, for the following reasons: 1) There are no truly mature tools for automatically generating and installing an initramfs based on system requirements. Canek likes to recommend dracut, which still isn't marked stable. I've gotten stable genkernel to work reasonably, but its error reporting is terrible. 2) There's no good means for applying software and security updates to an initramfs. If having an initramfs is to be considered the new normal, there should be some means of updating it as part of routine system updates. 3) With an initramfs and the tools to generate it, we have more moving parts were previously there were few. --=20 :wq