On Tue, Feb 11, 2020 at 10:09:52AM -0600, Justin Forbes wrote: > 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. Ack. I'll come back with a more concrete proposal. Zbyszek _______________________________________________ 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
