The udev provided by systemd will always be installed regardless of the init manager if the systemd is once built under the current build directory. How to reproduce? 1. build a systemd based image 2. build a sysvinit based image 3. start the image In step 3, we can see that the udev is actually provided by system. /sbin/udevd -> /lib/systemd/systemd-udevd Why? Once systemd is built, there will be a package in tmp/deploy/rpm with the name of 'udev-196-r1.i586.rpm'. Next time we build a sysvinit based image, there will be two udev packages under tmp/deploy/rpm. udev-196-r1.i586.rpm (systemd) udev-182-r4.i586.rpm (sysvinit) And the packagegroup-core-boot require udev, thus resulting udev-196-r1.i586.rpm installed instead of udev-182-r4.i586.rpm.
The same situation goes with udev-utils. Currently, I want to solve this problem by renaming udev provided by systemd to systemd-udev, and also udev-utils to systemd-udev-utils. Is there some better way to do this? Any thoughts and ideas are welcome.
how about use something looks like this: PREFERRED_VERSION_udev ?= ${@base_contains('DISTRO_FEATURES','sysvinit','182','',d)}
(In reply to comment #2) > how about use something looks like this: > > PREFERRED_VERSION_udev ?= > ${@base_contains('DISTRO_FEATURES','sysvinit','182','',d)} It seems that this method doesn't work. PREFERRED_VERSION_pkg controls which version of the pkg to build, so it works with the situation where there are multiple versions of recipes which have the same PN. For example, chenqi@pek-qchen1-d1:~/poky$ ls meta/recipes-kernel/linux/linux-yocto_3* -1 meta/recipes-kernel/linux/linux-yocto_3.0.bb meta/recipes-kernel/linux/linux-yocto_3.2.bb meta/recipes-kernel/linux/linux-yocto_3.4.bb In this case, we need to install the correct package from the DEPLOY_DIR. (Because of the PREFERRED_PROVIDER_udev setting, the correct udev has already been built.)
Please check with Ross and Radu on this issue.
"Currently, I want to solve this problem by renaming udev provided by systemd to systemd-udev, and also udev-utils to systemd-udev-utils" If we did that to make the rest of the packaging work sanely we'd need to have them RPROVIDE udev etc, and wouldn't the image creation phase pick the higher versions then? The problem is that deploy is "tainted", and isn't specific to systemd.
Created attachment 1033 [details] patch: systemd-rename-udev-to-systemd-udev
(In reply to comment #5) > "Currently, I want to solve this problem by renaming udev provided by > systemd to systemd-udev, and also udev-utils to systemd-udev-utils" > > If we did that to make the rest of the packaging work sanely we'd need to > have them RPROVIDE udev etc, and wouldn't the image creation phase pick the > higher versions then? > We can specify the dev manager in the following way. VIRTUAL-RUNTIME_dev_manager ?= "${@base_contains('DISTRO_FEATURES', 'sysvinit', 'udev', '', d)}${@base_contains('DISTRO_FEATURES', 'systemd', 'systemd-udev', '', d)}" And the PREFERRED_PROVIDER_udev is not needed any more. (See attached patch for more details.) > The problem is that deploy is "tainted", and isn't specific to systemd. Exactly. I see this as a problem because I think changing a distro feature should not result in a 'wrong' image. Best Regards, Chen Qi
Changing DISTRO_FEATURES in a given build directory has *never* been suported. I don't see why we'd want to start supporting this now. Admittedly it would be easier now than ever before due to sstate.
I do have a convenient wipe-deploy script that makes switching distro feature very easy. Change variable, wipe-deploy, rebuild.
(In reply to comment #9) > I do have a convenient wipe-deploy script that makes switching distro > feature very easy. Change variable, wipe-deploy, rebuild. Great! Would you like to share it? Mark this bug as 'RESOLVED NOTABUG'.