[oe] Kernel recipes with broken PRs now

[Phil Blundell]

On Sat, 2009-05-30 at 21:49 -0300, Otavio Salvador wrote:
> Hello,
> 
> On Sat, May 30, 2009 at 8:04 PM, Phil Blundell <philb at gnu.org> wrote:
> > My personal preference would still be just to make MACHINE_KERNEL_PR be
> > an opt-in thing per DISTRO.  I guess angstrom wants this: are there any
> > other distros that do?
> 
> My understand is that every distro that uses anything that needs ABI
> compatibility with kernel needs it, or is suppose to use it.

As I understand it, the situation that MACHINE_KERNEL_PR is meant to fix
is where both the following are true:

1) you have an external package (be that an out-of-tree module or some
other binary) which depends on some detail of the kernel ABI; and

2) the ABI in question is in fact changing, necessitating a rebuild,
even though the advertised ABI version (what we save in
kernel-abiversion) isn't

Emperically, since most DISTROs have been managing fine without
MACHINE_KERNEL_PR until now, it seems that either this situation isn't
arising very often in practice or the maintainers are managing to work
around it in some other way.  Whichever of those is the case, the need
for a solution to this problem doesn't seem to be very acute right
now.  

Further, it seems clear that the MACHINE_KERNEL_PR approach, as
currently implemented, has at least a few deficiencies:

a) it will cause PR to go backwards for kernel packages which haven't
been updated to match, and this will happen silently so the maintainers
may not realise at first what is going on;

b) it doesn't scale very well to the situation where you have either a
single kernel used by multiple MACHINEs, or a single MACHINE with
multiple kernels.  I suspect the former might be the case for some of
the ipaqs, and I'm fairly sure that the latter can be the case for some
models of zaurus.

c) it causes the kernel metadata to be scattered around the tree in a
slightly weird way, rather than localised to the kernel's own .bb file
where it arguably belongs.

d) it requires a rebuild of all out-of-tree modules for any kernel
change at all, even if the ABI was unaffected.

Now, none of these deficiencies are absolutely intolerable, and it's
perfectly understandable that some distro maintainers might decide to
put up with them in order to gain the perceived benefits of
MACHINE_KERNEL_PR.  But, for DISTROs and/or MACHINEs that weren't
suffering from the original problem in the first place, this patch will
simply introduce annoyances with no compensating benefits.

I think it would be quite possible to write a patch to fix the original
problems without introducing the deficiencies above, and if that were
done then there should be no downsides to enabling the patch globally.
But, as it stands today, I don't think that MACHINE_KERNEL_PR is
something that should be foisted on folks who don't want or need it.

p.