On Wed, Jul 18, 2012 at 3:20 PM, Canek Peláez Valdés <[email protected]> wrote: > On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol <[email protected]> wrote: >> On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés <[email protected]> >> wrote: >>> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol <[email protected]> wrote: >>>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner <[email protected]> wrote: >>> [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. -- :wq
