Hello, On Nov 17 08:42 m. allan noah wrote (shortened): > On Tue, Nov 17, 2009 at 6:42 AM, Julien BLACHE <jb at jblache.org> wrote: >> Johannes Meixner <jsmeix at suse.de> wrote: >> >>> What the heck has udev libsane.rules to do >>> with a particular kernel minor version number? >> >> That was a change in the USB layer in the kernel that needed a >> new/modified udev rule to create the device nodes. >> >> Now remember that the same people that brought you that unstable, >> ever-changing, ever-breaking USB stack are the same people who started >> and led udev for a while. Oh, and that little thing called >> "stable-api-nonsense.txt", too. > > While all of this may be true, it does not answer the original > question- If the distro is already producing a modified version of our > tool to turn .desc files into whatever format is required,
I think it answers the even the base of the original question: Regardless who tries to tame the udev monster, he is lost because nobody at userspace can tame the udev beast because it can change randomly at any time. Assume a user updates his kernel and randomly udev related stuff therein had changed. What should one do then? Provide our sane-backends package with a nice RPM requirement for a particular set of kernel versions so that it can no longer be installed at all only because of its special kernel/udev dependency, compare https://bugzilla.novell.com/show_bug.cgi?id=438867#c55 Or should I foster and nourish a nice zoo of various sane-backends packages (how should I name them all?) each for another set of kernel versions? No. I just tell the user to run saned as root on localhost plus the net meta backend to get udev/HAL mess out of sight. Intentionally it is a very easy to be set up by the YaST scanner module ;-) Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
