Re: udev: what does it used for in Debian?

[Ivan Shmakov <ivan@gray.siamics.net>]

>>>>> Neil Williams <codehelp@debian.org> writes:
>>>>> On Mon, 24 Oct 2011 18:19:08 +0700 Ivan Shmakov wrote:

 >> I've found that a few packages, contrary to my expectations, have
 >> Depends: on udev.  I'm primarily concerned with alsa-base and
 >> initramfs-tools, but also wonder about libcomedi0, dkopp,
 >> python-expeyes, libnjb5, media-player-info, pulseaudio, ukopp,
 >> xserver-xorg-core, and midisport-firmware.

 >> The backstory is that I'm about to install Debian (either stable or
 >> testing) on a tiny Architecture: i386 system, and consider excluding
 >> udev from the installation, as the hardware in question has
 >> virtually no support for any pluggable devices whatsoever.

 > udev isn't just for pluggable devices, packages can provide udev
 > rules to ensure that devices appear with a consistent name,

	It doesn't seem like a good reason for the aforementioned
	dependency, does it?

	And what the initramfs-tools package has to do with consistent
	devices' filenames?

 > e.g. /dev/input/event[0-9] does not include only pluggable or
 > external devices, it can contain several internal input devices as
 > HIDs but the actual number is not predictable. To make sure the
 > package reads from the correct device, it is wiser to provide a udev
 > rule which gives a particularly identified input device (by
 > classification / type / interface or even vendor) a known /dev
 > location as a name or symlink.

	Indeed, thanks.

	Somehow, I assume that given a relatively small number of
	devices per bus, this wasn't a problem, say, a decade or so ago.
	(Think of, say, 2 IDE or floppy drives per IDE or FDD
	controller, one keyboard, one PS/2 mouse, two RS-232 ports per
	UART, etc.)  Or was it rather that there was much less variation
	between different instances Intel-based computers' hardware?

	However, I wonder, how often these numbers will change given
	that the system's hardware configuration will essentially be
	fixed for all the foreseeable future?  I guess it won't be
	something like “every (other) kernel's release”, right?

	TIA.

-- 
FSF associate member #7257