Specifically, if you forget to do some piece of configuration, you now have enough piece in the initramfs to recover your system.> Having evms call update-initramfs at install time is completely gratuitous, > because the system *won't* be set up for evms at the time of the evms > postinst: either the update-initramfs will be a complete no-op and have to > be repeated later once evms is set up, or it won't be a no-op -- meaning it > will likely have done something undesirable, unrelated to evms. update-initramfs isn't a noop, it happily include all the needed evms root support, as evms added its hooks and calls update-initramfs.
> So I don't see any real benefit to having all of these tools rebuilding the > initramfs repeatedly during an upgrade cycle. Theoretically it would be > nice to know as soon as a package is installed that it will break the > initramfs, but using update-initramfs doesn't do this: the only way to be > sure whether a new initramfs is broken is to try to boot from it. Since we > can't force reboots during an upgrade (especially not once for each hook!), > there is no significant increase in predictability by using this method, and > users are better off if the upgrade doesn't touch the existing, working > initramfs images at all.
|
-- Although when you're in the situation that RMS is telling you that you're being too ideological about freedom, maybe, just maybe, it's true. - Matthew Wilcox |
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=