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 1SraW7-0002nz-6f for garchives@archives.gentoo.org; Wed, 18 Jul 2012 20:06:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D8322E0716; Wed, 18 Jul 2012 20:06:20 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by pigeon.gentoo.org (Postfix) with ESMTP id D2665E071D for ; Wed, 18 Jul 2012 20:05:41 +0000 (UTC) Received: by vcbfl17 with SMTP id fl17so1544251vcb.40 for ; Wed, 18 Jul 2012 13:05:41 -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 :x-gm-message-state; bh=KXV5oIliq6Lg0frEGZ0qqDfpVdJYgz0cEyzgFxpzUsw=; b=e3IFx63N40aSCKxfWhbqx0s8vmfmqeCBPzu54Coo60OIEyAoWEzTUjHPBM46kTmQKa 6wC+4vgwV3QotpouVG+NRMT5u5VEEl634ie5U0mIQXs/QFFU1KHccg9lUFlUoVjmymBj 0cJ1cnMQU1mutyz9UWqkUY0Jsa0hCFkEABSQwEDQjQTHbkBYrzxC0qzfsOWtmacvCvfT yvU45HwLdMJB8kgALgIiNdIg39AfSOhSrg8EvXGZiwbZa7Lk6rY3FVwejT0GM8Rn5hjN k3OFEzOojCCBLnEctbLr7JpZbAPR5SLRIlFhVMSF9EVHc51QwOogDvPrbKiuxFl892Kw p/Lg== 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.52.90.233 with SMTP id bz9mr1355461vdb.93.1342641941269; Wed, 18 Jul 2012 13:05:41 -0700 (PDT) Sender: antarus@scriptkitty.com Received: by 10.52.0.20 with HTTP; Wed, 18 Jul 2012 13:05:41 -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 13:05:41 -0700 X-Google-Sender-Auth: bFfzHQZPlt87XGa9xRJ4A6coq4E 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 X-Gm-Message-State: ALoCoQmWaJV+fQmYwXf81Rvc4ANUcgViTJU0KpE2d0i+c3VUnRgAE1RQh8Ey5YfVJmDRf4cygEqg X-Archives-Salt: c6dca309-875b-4226-b452-5b7e1ee8f90b X-Archives-Hash: 2721ef9987a9ad45bbe7dac6975ede8e On Wed, Jul 18, 2012 at 12:05 PM, Rich Freeman wrote: > On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol wrote: >> AFAIK, neither genkernel nor dracut were expected to get tied to the >> Gentoo update process. Has that changed? > > We don't even update kernels as part of the regular update process, > let alone initramfs systems. > > In general you update them together. > > The only issue I could see is if problems arise if you have a > different version of udev in your initramfs than on your system. I > don't know if that actually causes problems. For the most part after > the system is booted the initramfs is done its job. > > If some package did need a kernel/initramfs/etc to be updated it > should be the subject of news or an ewarn unless it becomes routine > practice. I don't think we want the system to start touching these > things without operator intervention unless we make it really > bulletproof like they do on big distros (the only reason they can is > they have one-size-fits-all kernels and initramfs designs). I'm not really following your logic here, so forgive me. I completely understand why folks do not say, rebuild their kernel when it is updated (kernel configs are annoying.) However lets say I have coreutils in / and coreutils in my initramfs. I upgrade coreutils from v1 to v2. Are you saying that you are too afraid to update coreutils in / and then also update it in the initramfs (probably by running $TOOL to copy coreutils from / to initramfs-root.) I'm not suggesting that we necessarily do this automatically, just that people claim 'the tools do not exist to do this now' when in fact it seems fairly straightforward to do. I mean presumably you used $TOOL to build the initramfs once, so running $TOOL again to generate a new initramfs probably should not screw you, provided you have control over the configuration of $TOOL. -A > > Rich >