Comment # 24 on bug 1202353 from Martin Wilck

(In reply to Michal Suchanek from comment #23)

> And the use case is what exactly?

All I know is that we've had intensive discussions in the past with some actors
inside the company that use our packages to build stuff that's different from
regular systems: installation images, KIWI or OBS build environments, special
containers, what not. I definitely have no oversight over these projects. These
people tend not to be involved on bugzillas like here, but they will complain
aferwards.

> In an imm������table image that is replaced whole if you have the kernel you also
> need the ramdisk, and need to build it. What/when/how does build the ramdisk?

I suppose the ramdisk could be built when the image is created, and dracut
could be removed afterwards. Also mind you that we're discussing immutable RAM
disks for FDE...

> And finally, if neither the kernel nor s-m-t pulls in dracut what does?

It's currently pretty messy (deps just from my system):

dracut
 <- kdump
    <- vm-install (only??)
 <- dracut-mkinitrd-deprecated
    <- mdadm (via /usr/sbin/mkinitrd)
       <- libbd_mdraid2
          <- udisks2 (via libblockdev-mdraid)
             <- gnome-disk-utility
             <- fwupd
 <- plymouth-scripts   
    <- plymouth-branding-openSUSE
       <- plymouth (via plymouth-branding)
          <- plymouth-dracut (sic?)

None of these deps looks necessary IMO, except kdump's. Or at least the
dependency of the kernel and s-m-t on dracut seems better justified than any of
these.

> Does potential space saving in a use case we do not have warrant enabling
> users of use cases we do have shooting themselves in the foot?

If it's consensus, I'm fine with adding Requires: dracut to s-m-t. According to
comment 12 and comment 21, it should  be ok for Factory. If those image folks
complain later, I'm innocent :-)