On Wed, 2012-10-17 at 11:38 -0700, Jesse Keating 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). > > > > 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. Random worry about this: would this work OK with yum's "keep the last 3 kernels around" functionality? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
