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 1SraiD-0004Eg-Ef for garchives@archives.gentoo.org; Wed, 18 Jul 2012 20:19:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 284E5E05FA; Wed, 18 Jul 2012 19:41:25 +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 0E402E0478 for ; Wed, 18 Jul 2012 19:40:47 +0000 (UTC) Received: by bkwj4 with SMTP id j4so1795230bkw.40 for ; Wed, 18 Jul 2012 12:40:47 -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=v0CZaHJQt3+363+MdV8tFLSTC2U0CkAzjp//19M3uyo=; b=ZeO/A20OEdnit14RoRSEjU19GXzcxMAU0UwyXgdZIm3Kb70nBMU/g7oysTdmh2bCtc iFFIUnSnchxNXAU+6Hnqr7x1/VGPxphmzndUKqwO1gPbzn+DQpf+/qq0G5Icw0FH4WRY P1TUBusyE4IrzTDVvqC2//R2gT1/0KP/aqZ6Qkth3EWK2OxDbkK24c8/rdr38dGU+MEq RxnVGW/m2VpS3USq7Dun5P8HKPGUKRMXLqqD5rMh7aewfKXqpW60W9uEVUArs9qYP8xC PxojB7TDlAwS2GKvsw2y5CVoUYBayRj8DHpLiPZUaycjnzEUgY6ZWVmo/6b6Lg/ajWTE c6yA== 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.145.90 with SMTP id c26mr2570286bkv.34.1342640447089; Wed, 18 Jul 2012 12:40:47 -0700 (PDT) Received: by 10.204.10.12 with HTTP; Wed, 18 Jul 2012 12:40:46 -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 15:40:46 -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: c5bf46a1-4021-49bc-97ce-43cb2b52ab81 X-Archives-Hash: 0b1acd9ca720be332034e301131d23f8 On Wed, Jul 18, 2012 at 3:20 PM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: > On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol wrote: >> On Wed, Jul 18, 2012 at 3:03 PM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: >>> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol wrote: >>>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner wrot= e: >>> [snip] >>>>> Debian uses initramfs-tools... >>>> >>>> AFAIK, neither genkernel nor dracut were expected to get tied to the >>>> Gentoo update process. Has that changed? >>> >>> The kernel you are running (if you update your machine) is not tied to >>> the Gentoo update process. The *source code* gets installed, but the >>> kernel source remains unchanged in /usr/src/whatever. It's the user >>> responsibility to configure, compile, and install the kernel (and then >>> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da) >>> genkernel, but it's not "tied to the Gentoo update process". >>> >>> I really don't see that much difference with needing to also update >>> the initramfs, if needed. >> >> What if your DNS resolver in your rescue shell has a vulnerability? >> What if wget, links or whatever network tools you use during recovery >> have a vulnerability? >> >> These are tools which are commonly placed in initramfs. > > First of all, none of this has nothing to do with the discussion at > hand. I completely disagree. If you take a step in a direction, you have momentum. So before you take a step in that direction, you should look where that momentum will carry you. > Second, I don't know what kind of initramfs you are familiar > with, but mine has nothing network related, and I don't see *any* > reason to include *anything* network related to an initramfs. So your initramfs doesn't include network tools such as ping, traceroute or wget. Fine. Fundamentally speaking, why shouldn't someone else's? > >>> Because, besides, if your /usr is not in a different partition, you >>> don't even *need* an initramfs. In that case not using an initramfs is >>> supported by all upstreams. >> >> And what of /var? /opt? > > What about them? Again, what it has this anything to do with our > current discussion? See my reply to Michal. > >> The problem with the /usr merge upstream is >> that someone didn't think things through when they pushed it, and the >> same reasoning used to justify it easily justifies changing the way >> /var and /opt are treated. > > That's pure speculation. I'll repeat myself. If you take a step, you have momentum. Before you take a step, you should see where that momentum will carry you. > Nobody has ever suggested merging /opt nor > /var; if I'm mistaken I would love to see even a single link (mail, > blog post, IRC discussion) were it was at least mentioned as a good > idea to do the same with /opt or /var. I'm pretty sure you don't have > any. I don't believe anyone *does* think it's a good idea, but I don't see how the arguments on behalf of a /usr merge don't operate in the same way on /var or /opt. If the argument is flawed for either of those two, I don't see how it isn't equally flawed for /usr. I've never seen where people have examined that in depth. --=20 :wq