Jon Masters wrote: > 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. Oh, duh. That's saner in that it does require this hack, and it does leave you with a fallback distro-provided kernel. But in the ARM case, the distro-provided kernel might not be bootable, so this method just wastes space and adds a non-functional boot target... > So would you ACK the importation of such a fake dep package? If it comes > up for debate? Does it really need to go into the main package repo? Aren't most secondary arches maintaining a handful of arch-specific bits in their own tree already anyway? I suppose long-term, and for it to be a reasonable option for other use cases, it should be in the main repo. I suppose I could get behind that idea. -- Jarod Wilson jarod@xxxxxxxxxx _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
