| Summary: | incorrect package conflict between two different images on same machine? | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Alex Olson <alex.olson> | ||||
| Component: | devtools / tool chain | Assignee: | Saul Wold <sgw> | ||||
| Status: | RESOLVED NOTABUG | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | mark.hatle, meta.mr.watcher, meta.watcher, sgw | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 1.5 | ||||||
| Hardware: | All | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
|
Description
Alex Olson
2013-06-10 17:31:44 UTC
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 |