https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c24 --- Comment #24 from Martin Wilck <martin.wilck@suse.com> --- (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 :-) -- You are receiving this mail because: You are on the CC list for the bug.