Bug#609300: Bug#633961: linux images must conflict with unfixed input-utils
On Mon, Jul 18, 2011 at 14:29:47 +0300, Adrian Bunk wrote: > How could a package declare "I need at least kernel 2.6.39"? You can't, and shouldn't, do that (at least until after the wheezy release). Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609300: 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/ | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609300: Bug#633961: linux images must conflict with unfixed input-utils
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"?
(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).
A patch for input-utils to remove the wrong version check is below.
After that, a Breaks in all kernel images on the unfixed input-utils
would be required.
> Ben.
cu
Adrian
<-- snip -->
--- input.c.old 2011-07-18 14:12:14.0 +0300
+++ input.c 2011-07-18 14:12:32.0 +0300
@@ -83,7 +83,7 @@
int device_open(int nr, int verbose)
{
char filename[32];
- int fd, version;
+ int fd;
snprintf(filename,sizeof(filename),
"/dev/input/event%d",nr);
@@ -96,17 +96,6 @@
if (verbose)
printf("%s\n",filename);
- if (-1 == ioctl(fd,EVIOCGVERSION,&version)) {
- perror("ioctl EVIOCGVERSION");
- close(fd);
- return -1;
- }
- if (EV_VERSION != version) {
- fprintf(stderr, "protocol version mismatch (expected %d, got
%d)\n",
- EV_VERSION, version);
- close(fd);
- return -1;
- }
return fd;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609300: Bug#633961: linux images must conflict with unfixed input-utils
On Fri, Jul 15, 2011 at 06:41:59PM +0300, Adrian Bunk wrote: > On Fri, Jul 15, 2011 at 03:45:58PM +0100, Ben Hutchings wrote: > > On Fri, 2011-07-15 at 16:04 +0300, Adrian Bunk wrote: > > > Package: linux-image-2.6.39-2-amd64 > > > Version: 2.6.39-3 > > > Severity: serious > > > > This is not RC for the kernel. > > "Upgrade makes another package completely unusable when not forcing an > upgrade of that" is not RC? Depends on the relative importance of the packages. > > > Upgrading the kernel without also upgrading input-utils (e.g. when > > > using the version in squeeze or the version currently in testing) > > > makes input-utils unusable (see #609300). > > > > > > After #609300 got fixed, the linux images should therefore add Breaks > > > for all non-fixed versions of input-utils. > > > > Maybe. But first you have to make input-utils work with both the kernel > > version in squeeze and the version in sid. > > A versioned build-dependency on linux-libc-dev and a breaks for older > kernel images seems to be the minimal fix. This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. 2. input-utils doesn't break them! They don't depend on input-utils; they'll keep on running. 3. You know how people complain about udev and kernel upgrade ordering dependencies? You're proposing to do the same thing. 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. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609300: Bug#633961: linux images must conflict with unfixed input-utils
On Fri, Jul 15, 2011 at 03:45:58PM +0100, Ben Hutchings wrote: > On Fri, 2011-07-15 at 16:04 +0300, Adrian Bunk wrote: > > Package: linux-image-2.6.39-2-amd64 > > Version: 2.6.39-3 > > Severity: serious > > This is not RC for the kernel. "Upgrade makes another package completely unusable when not forcing an upgrade of that" is not RC? > > Upgrading the kernel without also upgrading input-utils (e.g. when > > using the version in squeeze or the version currently in testing) > > makes input-utils unusable (see #609300). > > > > After #609300 got fixed, the linux images should therefore add Breaks > > for all non-fixed versions of input-utils. > > Maybe. But first you have to make input-utils work with both the kernel > version in squeeze and the version in sid. A versioned build-dependency on linux-libc-dev and a breaks for older kernel images seems to be the minimal fix. > Ben. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
