[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules
jsmeix at suse.de
Tue Nov 17 15:00:25 UTC 2009
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
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?
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 ;-)
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
More information about the sane-devel