On Wed, Oct 17, 2012 at 2:38 PM, Jesse Keating <jkeating@xxxxxxxxxx> wrote: > On 10/17/2012 11:32 AM, Chris Adams wrote: >> >> I would think the only "sane" way would be to just change the packaing, >> not actually build multiple kernels (or even multiple packages with >> kernels). We already build multiple kernels. All from the same source, but still multiple kernels with different config options. E.g. PAE, debug, etc. >> For example, a "kernel-minimal" that has the kernel and the "core" >> modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, >> network support like ipv6 and iptables, and virtio-type drivers), a >> "kernel-common" that has the rest of the current contents of "kernel" >> (and probably obsoletes "kernel"), and then the current >> "kernel-modules-extras". >> >> There will always be requests to move modules from -common to -minimal, >> and it shouldn't be a big fight (I would bet most requests would be >> pretty obvious). That already exists some for -modules-extras. > > > You'd want to do it something like that. > > kernel-minimal as you say but with a Provides: kernel, kernel-common as you > say. > > > I'd introduce a third metapackage just "kernel" that requires both of those > and implicitly Provides: kernel. Most people would just get the "kernel" > metapackage when a transaction asks for something to provide "kernel", but > if you explicitly ask for kernel-minimal you'd get just the minimal. > > This would all be done from one kernel spec and built out at the same time. > We've got a lot of new infrastructure coming for kernel builds and we don't > want to make things even more complicated by having to do multiple rpm build > runs. All of this can probably already be done with a new 'flavor' in the existing kernel.spec. I really wouldn't do the common/minimal split though. It just makes it more complicated for not a whole lot of gain. The idea that Dave, Justin, and Kevin all had simlutaneously about doing a 'kernel-virtguest' might be worthwhile if someone wants to spend time poking at a config, etc. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel