http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-165.tar.bz2 udev 165 ======== Bugfixes. The udev database has changed, After installation of a new udev version, 'udevadm info --convert-db' should be called, to let the new udev/libudev version read the already stored data. udevadm now supports quoting of property values, and prefixing of key names: $ udevadm info --export --export-prefix=MY_ --query=property -n sda MY_MAJOR='259' MY_MINOR='0' MY_DEVNAME='/dev/sda' MY_DEVTYPE='disk' ... libudev now supports: udev_device_get_is_initialized() udev_enumerate_add_match_is_initialized() to be able to skip devices the kernel has created , but udev has not already handled. libudev now supports: udev_device_get_usec_since_initialized() to retrieve the "age" of a udev device record. GUdev supports a more generic GUdevEnumerator class, udev TAG handling, device initialization and timestamp now. The counterpart of /sys/dev/{char,block}/$major:$minor, /dev/{char,block}/$major:$minor symlinks are now unconditionally created, even when no rule files exist. New and updated keymaps. Reproducible: Always
udev 166 ======== Bugfixes. New and updated keymaps. The format change of udev database makes me wonder how the update should be handled exactly. Additionally it seems we need code to detect a downgrade of udev and warn that a reboot may be necessary. In update case we should 1. stop old udev 2. then update database 3. wait for user to do etc-update/dispatch-conf 4. and then start the new udev.
sys-fs/udev-167 is in the tree which does the database conversion on the fly. So this bug can be closed as fixed I suppose.
(In reply to comment #2) > sys-fs/udev-167 is in the tree which does the database conversion on the fly. Yeah, this was a reason to wait for udev-167. But I guess we need a downgrade warning to reboot, as older udevs will not down-convert the database.
