| 1 |
On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol <mikemol@×××××.com> wrote: |
| 2 |
> On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
| 3 |
>> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol <mikemol@×××××.com> wrote: |
| 4 |
>>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner <antarus@g.o> wrote: |
| 5 |
>> [snip] |
| 6 |
>>>> Debian uses initramfs-tools... |
| 7 |
>>> |
| 8 |
>>> AFAIK, neither genkernel nor dracut were expected to get tied to the |
| 9 |
>>> Gentoo update process. Has that changed? |
| 10 |
>> |
| 11 |
>> The kernel you are running (if you update your machine) is not tied to |
| 12 |
>> the Gentoo update process. The *source code* gets installed, but the |
| 13 |
>> kernel source remains unchanged in /usr/src/whatever. It's the user |
| 14 |
>> responsibility to configure, compile, and install the kernel (and then |
| 15 |
>> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da) |
| 16 |
>> genkernel, but it's not "tied to the Gentoo update process". |
| 17 |
>> |
| 18 |
>> I really don't see that much difference with needing to also update |
| 19 |
>> the initramfs, if needed. |
| 20 |
> |
| 21 |
> What if your DNS resolver in your rescue shell has a vulnerability? |
| 22 |
> What if wget, links or whatever network tools you use during recovery |
| 23 |
> have a vulnerability? |
| 24 |
> |
| 25 |
> These are tools which are commonly placed in initramfs. |
| 26 |
|
| 27 |
First of all, none of this has nothing to do with the discussion at |
| 28 |
hand. Second, I don't know what kind of initramfs you are familiar |
| 29 |
with, but mine has nothing network related, and I don't see *any* |
| 30 |
reason to include *anything* network related to an initramfs. |
| 31 |
|
| 32 |
>> Because, besides, if your /usr is not in a different partition, you |
| 33 |
>> don't even *need* an initramfs. In that case not using an initramfs is |
| 34 |
>> supported by all upstreams. |
| 35 |
> |
| 36 |
> And what of /var? /opt? |
| 37 |
|
| 38 |
What about them? Again, what it has this anything to do with our |
| 39 |
current discussion? |
| 40 |
|
| 41 |
> The problem with the /usr merge upstream is |
| 42 |
> that someone didn't think things through when they pushed it, and the |
| 43 |
> same reasoning used to justify it easily justifies changing the way |
| 44 |
> /var and /opt are treated. |
| 45 |
|
| 46 |
That's pure speculation. Nobody has ever suggested merging /opt nor |
| 47 |
/var; if I'm mistaken I would love to see even a single link (mail, |
| 48 |
blog post, IRC discussion) were it was at least mentioned as a good |
| 49 |
idea to do the same with /opt or /var. I'm pretty sure you don't have |
| 50 |
any. |
| 51 |
|
| 52 |
Regards. |
| 53 |
-- |
| 54 |
Canek Peláez Valdés |
| 55 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 56 |
Universidad Nacional Autónoma de México |
Archives