On Tue, Feb 11, 2020 at 7:16 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Mon, Feb 10, 2020 at 02:37:13PM -0500, John Florian wrote: > > Can this be improved? I'm sure it can be. I'm genuinely curious > > what dracut does that an rpm couldn't ship. I'd also hate to lose > > the versatility that we have at the present. I've been very > > successful with what Fedora has offered, but I've always been scared > > of autonomous nodes building/booting their own special initrd's and > > hoping all just works. > > Hi, > > I think this discussion has gone further than intended. I'm not > proposing Fedora changes the way initramfs is being done; it's way too > early for this at this point. Rather, I was asking for making the > packaging of kernel more flexible. One of the uses might the initramfs > stuff, but this type of changes is generally useful for minimization, > e.g. for VM images. I think other cases would pop up too. > > As to the question of the flexibility of dracut: it is flexible. But > this flexibility is completely orthogonal to how the image is put > together: if the image was built by installing some rpms, it'd still > be possible to do whatever changes from a plugin after those rpms > have been installed. Please consider e.g. how os-build does this (there > was a nice talk at devconf). > This is all relevant discussion though, as we really do need to know a) exactly how people are wanting the kernel split up, and b) what is the exact benefit of doing so. Here's the thing. People ask for the kernel to be split up in various ways almost yearly at this point. Everyone wants something different. Splitting the kernel is a hard thing to do without messing up people's systems, and it can get out of hand *very* quickly. I am not opposed to changing the kernel packaging if we can prove real benefit to doing so, AND can prove it isn't going to cause problems for existing users, or an ongoing nightmare for maintainers. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
