As the description says, I think it is better to let sys-fs/device-mapper itself install the related udev rules file /etc/udev/rules.d/64-device-mapper.rules. This ways the rules also can use the new parameters dedicated for udev interfacing Kay added to device-mapper without even more ugly version checks inside udev ebuild. The move can be protected by blockers if necessary. A. All older udev ebuilds blocking new added device-mapper ebuild. B. New device-mapper ebuild blocking older udev ebuilds.
According to jakub we don't need blockers for CONFIG_PROTECTED files. That means just adding the file to device-mapper will work. @robbat2: Is it ok, that I just bump device-mapper to 1.02.19-r1 and add that file? And then either immediately, or some weeks later remove it from udev-ebuild.
zzam: Ok with me if you just add it via a bump. Related question, how can we get it cleaned up for users that don't use device-mapper (since udev won't add any new version, but the old one will remain).
I suggest adding this to udev's pkg_postinst: # 64-device-mapper.rules now gets installed by sys-fs/device-mapper # remove it if user don't has sys-fs/device-mapper installed if has_version "<sys-fs/udev-113" && [[ -f "${ROOT}"/etc/udev/rules.d/64-device-mapper.rules ]] && ! has_version sys-fs/device-mapper then rm -f "${ROOT}"/etc/udev/rules.d/64-device-mapper.rules einfo "Removed unneeded file 64-device-mapper.rules" fi And to catch the ugly case of emergeing device-mapper. Then udev-112-r1, and then udev-113 I suggest to add this to pkg_preinst of udev to change mtime of file, and portage will not remove it: if has_version "<sys-fs/udev-113" && [[ -f "${ROOT}"/etc/udev/rules.d/64-device-mapper.rules ]] && has_version sys-fs/device-mapper then # change mtime to definitely keep the file touch "${ROOT}"/etc/udev/rules.d/64-device-mapper.rules fi
Commited sys-fs/device-mapper-1.02.19-r1 and sys-fs/udev-113. Move done!
