opkg install nativesdk-buildtools-perl-dummy nativesdk-texinfo The log would say nativesdk-buildtools-perl-dummy conflicts with nativesdk-perl so that nativesdk-texinfo is not installed, but the first one provides nativesdk-perl, so this is incorrect. Similar issue to reproduce: PACKAGE_CLASSES = "package_ipk" bitbake buildtools-tarball, we will say that nativesdk-perl and nativesdk-buildtools-perl-dummy are installed, but it shouldn't since nativesdk-buildtools-perl-dummy provides nativesdk-perl, and it is required by user to install. (in TOOLCHAIN_HOST_TASK which is translated into command line).
To expand the problem: buildtools-tarball built with opkg contains perl when it shouldn't, when built with rpm it doesn't contain perl. The tarball *should not* contain perl.
Alejandro: do you have any thoughts on this?
Expansion for Alejandro: the buildtools-tarball essentially depends on nativesdk-buildtools-perl-dummy and nativesdk-texinfo. -perl-dummy provides/conflicts with nativesdk-perl so with those install requests perl-dummy and texinfo should both be installed. However, opkg appears to ignore the explicit request and installs the real nativesdk-perl instead.
I can confirm this is bug on opkg (it's been there for a while, I think). If you have: Package a, which Depends on x Package b, which Provides x and Conflicts x Package x and you install a, then try to install b, you'll get an incorrect error: adelcast@delcastillo2 ~/git/opkg/tests $ opkg -o /tmp/opkg install a Collected errors: * check_conflicts_for: The following packages conflict with x: * check_conflicts_for: b * * opkg_solver_install: Cannot install package a. This is only a problem with the internal solver (default), the libsolv backend does let you install a. You can assign the bug to me. I am going to be at SaltConf next week, hope that's ok (don't know if this is holding the 2.1 release)
How well tested is the libsolv backend? Should we consider switching? Personally I'm thinking that we should ensure the release notes mention this and ensure that anyone building buildtools is using rpm (we can enforce this at build time), and backport the fix when it's ready.
Unfortunately, the libsolv backend it's not ready for prime time yet. Regarding a fix, I think I can have something fairly quickly once I get back (Monday 25th). Could have something before then if it's important...(not that familiar with buildtools)
Paul has a workaround, when that is merged we'll close this but I'll open a bug specifically against opkg.
good, to hear....I assume he suggested to add a Replaces too? I think the combination Provides/Conflicts/Replaces is well tested... thanks for opening a bug report on opkg, I worked a bit on a solution yesterday...should be able to include it as part of the 0.3.2 release (June)
Yes, the fix was a replaces.
The nativesdk-buildtools-perl-dummy case is worked around by oe-core b18134ddaf949b4f001a1613ab876aed6324040a (bug 9469). The general case is filed against opkg as bug 9477. *** This bug has been marked as a duplicate of bug 9477 ***
Verified.