https://bugzilla.suse.com/show_bug.cgi?id=1191322 https://bugzilla.suse.com/show_bug.cgi?id=1191322#c3 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #3 from Martin Wilck <martin.wilck@suse.com> --- (In reply to Takashi Iwai from comment #1)

There has been already discussions and some ongoing works about the optimization of initrd creation.

Indeed. We have an open feature request for SLE, and I'm actively working on this topic for the upcoming SUSE labs conference. There are plenty of ways to optimize this, and dare say I've explored most of them. We still have some way to go until all of this is properly tested and ready for release. (In reply to Michal Suchanek from comment #2)

posttrans is broken - it only runs on install, not on uninstall.

When uninstalling the ramdisk has to be rebuilt right away.

It's true in principle, but we'll be able to deal with this restriction. We shouldn't rebuild the initrd *at all* when we remove a kernel subpackage like kernel-default-extra. We currently don't anyway, because of bug 1191200, and haven't been doing it for more than a decade, without anyone complaining. In the vast majority of cases, when a kernel subpackage is removed, the corresponding base package is removed as well (because it happens in the course of a kernel update or purge-kernels run). Rebuilding the initrd for a kernel that's going to be removed a few seconds later is obviously a waste of time. In the remaining cases, someone may have installed kernel-default-extra or some other subpackage, realizes that he doesn't need/want it any more, and uninstalls it. He wouldn't do this if the kernel-default-extra contained any modules that were essential for his system to boot. And even if there were any (some crypto modules from -extra tend to be added to the initrd always), what harm would be done if they remain in the initrd while the package they belong to has been removed? The only reason to do that would be some abstract "correctness". But in practice, this doesn't justify to waste the users's time by rebuilding the initrd in the common case, when it's absolutely pointless. It's true that when the %preun or %postun scripts of a kernel subpackage is run, we have no way to determine whether or not the base package is going to be removed. AFAICT it's not possible to retrieve this information without changes in rpm, libzypp, or both. Therefore we have to make a guess, and we should guess that the base package will be removed, because it's the common case, and because we can't do harm if we guess wrong. -- You are receiving this mail because: You are on the CC list for the bug.