[PATCH 1/6] use embedded input_local.h instead of system linux/input.h

[Michael Biebl]

2008/11/3 Matthew Garrett <mjg59 at srcf.ucam.org>:
> On Mon, Nov 03, 2008 at 01:50:39AM +0100, Michael Biebl wrote:
>> 2008/11/3 Matthew Garrett <mjg59 at srcf.ucam.org>:
>> > But can be handled by the distribution, rather than distributions
>> > needing to remember to recompile hal every time they update the kernel.
>> > That kind of tight binding is a pain to deal with.
>>
>> That still doesn't make sense to me.
>> Now the distribution has to remember to update the local copy and
>> recompile hal whereas they simply have to recompile on a kernel
>> upgrade.
>
> No, hal upstream updates whenever the kernel gets updated (in order to
> support the new functionality of the kernel) and then downstream
> distributions pick it up automatically. That way only one set of people

Yeah, and this thight coupling actually would be a pita, as then hal
would dictate what kernel can be used (or vice versa).
Say, your distro decides to go with 2.6.27 for you next release, then
you'd have to pick a hal release which supports that version in
local_input.h or you have to start patching local_input.h. That would
we a major headache.

> need to care about the kernel/hal coupling, rather than us having a
> myriad collection of bugs where the same version of hal has different

I've never seen such bug reports against the Debian hal package. If
there are myriad of such bugs, could you point me to one?

I fear that this new change will actually make it harder for distros
and cause much work.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?