Bug#633961: linux images must conflict with unfixed input-utils
On Mon, Jul 18, 2011 at 02:29:47PM +0300, Adrian Bunk wrote:
> tags 609300 +patch
> thanks
>
> On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote:
> >...
> > This is wrong on so many levels.
> > 1. There is no way to declare relations to 'all kernel packages'.
>
> Why not?
>
> How could a package declare "I need at least kernel 2.6.39"?
See http://packages.debian.org/search?keywords=linux-image-2.6.39-2 for
the kernel you'd have to depend on only to cover 2.6.39 and not all
future kernels with all then valid featuresets.
And note that a machine having installed 2.6.39 but runs 2.6.32
satisfies that Depends. So you need a runtime check.
($(uname -r) >= 2.6.39)
> (I know that self-compiled kernels are a different story, but for
> kernel packages that should be possible.)
>
> >...
> > 3. You know how people complain about udev and kernel upgrade ordering
> > dependencies? You're proposing to do the same thing.
>
> udev is a special case, since it is very essential and udev and kernel
> upgrade ordering was a tricky problem.
>
> input-utils is a peripheral package without much hassle.
>
> > I suspect that the correct way to deal with this may be to build
> > input-utils from the linux-2.6 source package and add some sort of
> > wrapper in linux-base to select the right version (like we do for
> > perf).
> >
> > Or, you change the program to check which protocol version to use at
> > run-time.
>
> After looking a bit into it, and especially at commit ab4e0192
> (Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2) in
> the kernel, the correct fix for input-utils is a different and
> quite simple one:
>
> The input kernel<->userspace API might be enhanced with additional
> functionality in the future, but it will never change in a way that
> breaks the ABI.
>
> Therefore the old functionality input-utils is using will always
> be available, and the bug was that EVIOCGVERSION shouldn't be used
> to check with equality for EV_VERSION (version >= 0x010001 might
> be a valid check for software using EVIOCGKEYCODE_V2).
I think this is the way to go.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Reply to: