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 :)
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?