9464 2016-04-14 07:39:17 +0000 opkg: can't handle conflicted pkgs correctly 2016-05-04 10:51:10 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 2.2 x86 Multiple VERIFIED DUPLICATE 9477 Medium+ major 2.1 M4 1 liezhi.yang ross.burton alejandro.delcastillo alexandru.costinx.roman meta.mr.watcher meta.watcher richard.purdie alexandru.costinx.roman --- --- No (bug/feature does not impact docs) oldest_to_newest 61190 0 liezhi.yang 2016-04-14 07:39:17 +0000 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). 61229 1 ross.burton 2016-04-14 15:15:54 +0000 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. 61237 2 ross.burton 2016-04-14 16:00:49 +0000 Alejandro: do you have any thoughts on this? 61239 3 ross.burton 2016-04-14 16:11:17 +0000 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. 61305 4 alejandro.delcastillo 2016-04-15 19:39:18 +0000 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) 61306 5 ross.burton 2016-04-15 20:27:07 +0000 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. 61308 6 alejandro.delcastillo 2016-04-15 20:55:57 +0000 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) 61333 7 ross.burton 2016-04-18 12:37:54 +0000 Paul has a workaround, when that is merged we'll close this but I'll open a bug specifically against opkg. 61346 8 alejandro.delcastillo 2016-04-18 15:16:51 +0000 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) 61347 9 ross.burton 2016-04-18 15:26:11 +0000 Yes, the fix was a replaces. 61813 10 ross.burton 2016-04-28 17:28:41 +0000 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 *** 61923 11 alexandru.costinx.roman 2016-05-04 10:51:10 +0000 Verified.