(Sorry, I'm not sure how to categorize this bug) I am attempting to build two different root filesystems images containing two different sets of packages under the same MACHINE. The two root filesystems are built using separate 'image' recipes which contain similar (but different) packages. - Both IMAGE1 and IMAGE2 recipes are derived from core-image-minimal - IMAGE1 also contains the 'MYPKG1' package - IMAGE2 also contains the 'MYPKG2' package - IMAGE1 does not contain MYPKG2 anywhere in its dependencies - IMAGE2 does not contain MYPKG1 anywhere in its dependencies - MYPKG1 and MYPKG2 contain the same files but are compiled differently - MYPKG1 and MYPKG2 do not depend on each other at all and nothing else depends on them (other than the respective image recipes). Oddly enough, if I built 'IMAGE1' and then attempt to build IMAGE2 (using separate bitbake invocations), I get an error from the 'rpm' utilities that MYPKG1 and MYPKG2 are both being installed and that their files conflict. However, running 'bitbake -g IMAGE1' and 'bitbake -g IMAGE2' indeed shows that MYPKG1 is only in the dependency chain of IMAGE1 and MYPKG2 is only in the dependency chain of IMAGE2. For the time being, I have switched to 'ipk' for package management and do not see any issues, but I'm trying to better understand what is really going on... [There is also an unrelated(?) issue that MYPKG1 and MYPKG2 are both staged to sysroot despite no other package needing them in the sysroot.]
Actually, the issue is beyond rpm.
Actually, the issue is not rpm-specific. I see the same problem with ipk package management too. The only thing that seems to help is to add RPROVIDES / RREPLACES lines to each package so that they both provide and replace a virtual package. However, its not obvious why this is actually doing.
Created attachment 1256 [details] toy example showing problem Build image "bug-rootfs-one" and then attempt building "bug-rootfs-two". "bitbake -e bug-rootfs-one" confirms that only dependency is on "app-one", not "app-two". "bitbake -e bug-rootfs-two" confirms that only dependency is on "app-two", not "app-one". However, attempting to build "bug-rootfs-two" will fail with the following message. [NOTE: The "Installing Packages" list below contains BOTH app-one AND app-two. (This makes no sense to me)] | | Note: configuring RPM cross-install scriptlet_wrapper | | Updating cache... ######################################## [100%] | | Saving cache... | | Note: adding Smart RPM DB channel | | Note: to be installed: rpm-postinsts@all packagegroup-core-boot@hp_qemu file@i586 app-two@i586 | Loading cache... | Updating cache... ######################################## [100%] | Committing transaction.... | Preparing... ######################################## [ 0%] | error: file /usr/lib/libapp.so.1 conflicts between attempted installs of app-two-1.0-r0.i586 and app-one-1.0-r0.i586 | | | Installing packages (31): | app-one-1.0-r0@i586 | app-two-1.0-r0@i586 | base-files-3.0.14-r73@hp_qemu | base-passwd-3.5.26-r2@i586 | busybox-1.20.2-r7@i586 | busybox-hwclock-1.20.2-r7@i586 | busybox-syslog-1.20.2-r7@i586 | busybox-udhcpc-1.20.2-r7@i586 | file-5.13-r0@i586 | init-ifupdown-1.0-r0@i586 | initscripts-1.0-r140@i586 | libblkid1-2.22.2-r3@i586 | libc6-2.17-r3@i586 | libkmod2-9-r0.0@i586 | libuuid1-2.22.2-r3@i586 | libz1-1.2.7-r0@i586 | modutils-initscripts-1.0-r6@i586 | netbase-1:5.0-r0@i586 | packagegroup-core-boot-1.0-r11@hp_qemu | pciutils-ids-3.1.10-r0@i586 | rpm-postinsts-1.0-r0@all | sysvinit-2.88dsf-r11@i586 | sysvinit-inittab-2.88dsf-r9@hp_qemu | sysvinit-pidof-2.88dsf-r11@i586 | tinylogin-1.4-r9@i586 | udev-182-r7@i586 | udev-extraconf-1.0-r8@i586 | udev-utils-182-r7@i586 | update-alternatives-cworth-1:0.1.8+svnr649-r13.0@i586 | update-rc.d-0.7-r5@all | usbutils-ids-006-r0@i586
This may not be a bug, there is a design decision to ensure that there are no conflicting files installed, as you noted with your sysroot comment you are attempting to install the same file for different recipes, the system warns you about this. We don't want 2 different recipes providing the same file. It seems you have worked around your sysroot issue, with the correct change. I was not able to reproduce your RPM example with the meta-bug layer, I built both rootfs and they built correctly and contained the correct app_main and libapp files associated with their respective images. If you can be me any more details, or your local.conf
The system does various remapping activities when it discovers shared libraries. This is not package specific in any way. When the system detects a shared library it scans various information (i.e. soname) and stores that in a cache. When the system detects an ELF binary, it checks for soname requirements.. uses the cache and fills out dependency information based on that cache. Since you have two packages that provide the same cached entry, the system has no idea which you want -- so it chooses the first one and that becomes the package dependency. As far as I know what you are attempting to do is invalid. it MIGHT be possible to do this using the alternatives system, but I'm not sure...
Sorry, I didn't get to address Saul's early comment in time. I (somewhat blindly) assumed that if rpm "A" depends on 'libB.so' which is provided by two separate rpms "B1" and "B2", that something like "rpm -I A.rpm B1.rpm" might work... [but never tried it]. In such a hypothetical case, all dependencies would be satistied from the set of to-be-installed + installed packages... I have never used SmartRPM before and do not know how/if it differs from rpm/yum in a typical Redhat/CentOS environment... The automatic dependency tracking when 'rpm' packaging in Yocto is used seems to be a bit of a double-edged sword. The 'Yocto' view of package dependencies and the 'rpm' view aren't necessarily the same... This both finds missing dependencies in Yocto recipes as well and either causes build failures or unexpected packages in the rootfs [such finding perl because a single package had a single utility perl script not critical for normal operation] Thanks for taking time to address this issue. Feel free to close it as "stupid user error"
Closed at the request of the submitter