Comment # 3 on bug 1191322 from Martin Wilck

(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.