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
> <zbys...@in.waw.pl> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to