On Fri, Dec 30, 2011 at 11:19 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
This is quite logical: why depend on a several years old kernel, but use the latest and greatest udev? Those things are tied together quite closely.
You are right. We should expect this to cause us problems sooner or later.
That commit was done 5 months ago and is in udev since release 173. Did we ever receive any bugreport about 2.6.32 not working? The readme file has stated 2.6.34 requirement for a long time now, and still does that. So maybe there's no problem at all and things still work fine with 2.6.32. As long as our LTS kernel has the options compiled in as required by udev, I don't think it will become a huge problem.
Since then, several "legacy" things have been dropped from udev (support for the ide subsystem comes to mind), and until recently there was some ambiguity in the README stating that .32 was also supported. This has now been removed. I have not received any bug reports regarding our -lts. This sort of makes sense as what is likely to break is support for peripherals or udisks and friends. If -lts is used on a server without using any fancy udev features (such as /dev/disk-by-*, cdroms, printers, ...), there is no reason anyone should notice. So things are likely to limp along just fine. However, I thought it would make sense to point out that something is not quite right. Especially as the people who use -lts are likely doing that because they want something well tested, but they are getting the opposite. On a more productive note: I'll be looking into exactly what is missing in .32, and how big problems we should expect. If people want to improve the udev-compat rule files, get in touch with me and I can point you in the right direction as I have some ideas. -t