On Wed, 2011-06-08 at 14:15 -0400, Jarod Wilson wrote: > Jon Masters wrote: > > On Wed, 2011-06-08 at 11:14 -0400, Jon Masters wrote: > > > >> What do the kernel maintainers think about having a kernel subpackage > >> that just provides fake deps as part of the main kernel package? > > > > Anyway. To get back to the point...there are some systems that cannot > > run a stock Fedora kernel yet or need fake kernel deps for other > > reasons. Is there any fundamental objection to the fake-kernel package > > being integrated by way of an official kernel sub-package? (perhaps even > > selectively buildable and not built by default on e.g. x86?). > > Do not want. This is just as easily accomplished by a separate spec that > doesn't clutter up the official kernel spec even further than it already is. That's fine, it's ok in a separate package. I just wanted to raise it. > A kernel-none package would, however, be potentially amusing to even > relatively sane arches like x86. Install the kernel-none variant, and > you don't get kernel updates via yum, which may be desired, if you're > running your own locally built kernel and don't want the bootloader > constantly being updated to point to the newly installed kernel rpm when > you really want the locally built kernel to keep being the default boot > kernel... But this has no way of working in Anaconda, which is another > reason why I think it has no place in the actual kernel spec. Good points. I generally add kernel to the excludes line in my x86 yum configs, which achieves similar but I still think there are similar uses for this even if that particular one can be handled elsewhere. For installing, yea, there needs to be a kernel package that at least supports some targets, which is where this is headed. For example, I see a general ARMv7 kernel that supports a good subset of targets as the most likely option in the medium term. I don't see it likely that we'd have a one size fits all kernel image in the next few weeks :) > I presume > people "installing" on ARM are creating an image on another host, rather > than actually running through an anaconda install. Right. At the moment, there are scripts to generate a rootfs (and I will be posting a more up to date rootfs example image with pre-canned kernel and bits for some targets soon), but the goal is to get to a point: 1). Where the rootfs image can be generated using appliance creation tools that already exist, since many boards are similarly used. 2). Eventually, where we have support for standard installation. I suspect that would be using a kernel that supports major systems, but where if you have something more exotic, you still install the fake dependency package (after perhaps building an image) on your own. So would you ACK the importation of such a fake dep package? If it comes up for debate? Jon. _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
