Keeping up with the Kroah-Hartmans (who upgrade without notice) [LWN.net]

Keeping up with the Kroah-Hartmans (who upgrade without notice)

Posted Aug 4, 2006 4:32 UTC (Fri) by xoddam (subscriber, #2322)
In reply to: Keeping up with the Kroah-Hartmans (who upgrade without notice) by jschrod
Parent article: New kernels and old distributions

> If you would have read the linked full email from Andrew,

Actually I did read it, but I missed this detail.

> you would have seen:

> > This stuff breaks my FC3 test box and there is, afaict,
> > no clear way for users to upgrade udev to unbreak it.

> (emphasis mine). Thus, your solution doesn't seem to work.

You are correct at the time of writing. I'd consider this a bug in udev
rather than the kernel. A workable solution would be sticking `uname -r`
in the path to the udev daemon binary, as suggested below and as is
currently done for modules. This would be a reasonable change for
updated kernel and udev packages to make for older distributions. People
who build their own kernels are capable of hacking such a change by hand.

(Log in to post comments)

Keeping up with the Kroah-Hartmans (who upgrade without notice)

Posted Aug 4, 2006 8:41 UTC (Fri) by jschrod (subscriber, #1646) [Link]

I'm with you that a solution that would require kernel and udev upgrade at the same time would be workable. E.g., I run a self-compiled kernel on my laptop, to get suspend2, and I would surely find it acceptable. But my SUSE 9.2 is more than 10 month old and is therefore supposed to be hit by the introduced change by Greg -- and that I don't find acceptable without a clear upgrade path for udev... :-) (I have to say that I didn't test it the patch, but want to wait until the dust of this discussion has settled.)

The problem is not that there are possibilities to handle the change; the problem is that Greg does the change without the possibilities in place. Wasn't it Greg in his OLS talk that promoted the high quality of the kernel and wanted more users to test the latest mainstream kernels, besides the kernel developers themselves? Well, then he has to care more about user requirements and user problems, like Andrew does.

Cheers, Joachim