| 1 |
On Wed, Jul 18, 2012 at 4:05 PM, Alec Warner <antarus@g.o> wrote: |
| 2 |
> |
| 3 |
> I'm not really following your logic here, so forgive me. I completely |
| 4 |
> understand why folks do not say, rebuild their kernel when it is |
| 5 |
> updated (kernel configs are annoying.) |
| 6 |
> |
| 7 |
> However lets say I have coreutils in / and coreutils in my initramfs. |
| 8 |
> I upgrade coreutils from v1 to v2. Are you saying that you are too |
| 9 |
> afraid to update coreutils in / and then also update it in the |
| 10 |
> initramfs (probably by running $TOOL to copy coreutils from / to |
| 11 |
> initramfs-root.) |
| 12 |
|
| 13 |
As others have mentioned, coreutils doesn't impact the initramfs much |
| 14 |
anyway, though other tools like mdadm/lvm/etc are more likely to. |
| 15 |
|
| 16 |
I think the more practical issue is that it isn't straightforward to |
| 17 |
do in an automated way. I suppose we could keep an always-up-to-date |
| 18 |
kernel and initramfs SOMEWHERE, but that won't necessarily be where |
| 19 |
the user boots it from. Also, we need flexibility as users tend to |
| 20 |
tweak these things - dracut has lots of options for how the initramfs |
| 21 |
is built, users might use any of several initramfs implementations, |
| 22 |
and the kernel config is frequently tweaked, and doesn't always work |
| 23 |
if you just do a make oldconfig. Usually the way other distros make |
| 24 |
all of this work is by making everything generic and not support |
| 25 |
configurability. |
| 26 |
|
| 27 |
Rich |
Archives