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 1SrZIC-0001mA-P2 for garchives@archives.gentoo.org; Wed, 18 Jul 2012 18:48:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A985AE0525; Wed, 18 Jul 2012 18:47:57 +0000 (UTC) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by pigeon.gentoo.org (Postfix) with ESMTP id CA9DAE0205 for ; Wed, 18 Jul 2012 18:47:08 +0000 (UTC) Received: by vbbfc26 with SMTP id fc26so1500011vbb.40 for ; Wed, 18 Jul 2012 11:47:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=QEJoVuIgdRTtdGQeAda1Lr40yRC94UrU60U64kutzmI=; b=ozOiiBA6TXNZzi4+Wly30dyagFHF73XeUJaIKs4SUbue/PSUBN4m9DPr3iC6WRHAbI /30ykGDZMs5iYUW9CFf2MwUYvsuHicEyX2uKIUxap26R8LJ1uuFEVGyD7FPEqNBHMJoB 42d4SWM+/CYXSLV6dKCDNIqyJW/I8NIUqGTiNMinOlhiZYzrCNnz+N3x6KeaPDOiJLWO 60lAFmlk/Ci6ARA9OLcUBVHcE2xzjX5H4Qmh/oJqEIcingZyqwqZEG2jjsu/xxNIjREe l/whLot9oh7eSPgozq8ylqWottUGuz+Zykf30hNNJ9+UYWbzHDVb1ukajp9WcNDZFhm3 6QsA== 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.220.214.208 with SMTP id hb16mr1404276vcb.56.1342637228387; Wed, 18 Jul 2012 11:47:08 -0700 (PDT) Sender: antarus@scriptkitty.com Received: by 10.52.0.20 with HTTP; Wed, 18 Jul 2012 11:47:08 -0700 (PDT) In-Reply-To: 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 20:47:08 +0200 X-Google-Sender-Auth: U4hvpdUHywmkw-7Iou7g74jfRB0 Message-ID: Subject: Re: [gentoo-dev] Opinion against /usr merge From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkqm0bkwu3u0BQKbD1axJOFI/hBssKjn7hxh9qpBEC3TxXVQM/oTMMpQVkKpM/AS6suFvRW X-Archives-Salt: 7bd8028e-4f31-4d45-a298-987f28e7a33a X-Archives-Hash: a3d720011632d5831b0368ba7c8a31b4 On Wed, Jul 18, 2012 at 8:25 PM, Michael Mol wrote: > 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. Debian uses initramfs-tools... > 3) With an initramfs and the tools to generate it, we have more moving > parts were previously there were few. > > -- > :wq >