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(a)redhat.com