[fedora-arm] adding fake-kernel to repository

[Jarod Wilson]

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 at redhat.com