Bug 8360 - [internalsolv] Packages fail to install when Recommends can't be installed (old issue #165)
Summary: [internalsolv] Packages fail to install when Recommends can't be installed (o...
Status: ACCEPTED
Alias: None
Product: opkg
Classification: Yocto Project Subprojects
Component: opkg (show other bugs)
Version: 0.3.0
Hardware: x86 Multiple
: Undecided minor
Target Milestone: ---
Assignee: Alex Stewart
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2015-09-21 01:24 UTC by Alejandro del Castillo
Modified: 2021-07-08 15:11 UTC (History)
0 users

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alejandro del Castillo 2015-09-21 01:24:58 UTC
What steps will reproduce the problem?
1.Create packages 'x', 'a', and 'b' such that 'a' recommends 'b', and 'b' conflicts 'x'
2. Install 'x'
3. Try to install 'a'

What is the expected output? What do you see instead?
I expect 'a' to be installed, since 'b' is not an absolute dependency of 'a'.

Instead, nothing is installed.

What version of the product are you using? On what operating system?
0.3.0

Please provide any additional information below.
There are several other set-ups that cause related problems. For example if 'a' recommends 'b' and 'c', but 'c' conflicts with 'x', then only 'b' is installed and 'a' remains uninstalled. Note this is different from issue 162 since we do expect the non-conflicting packages to be installed in this case since recommends does not signal an absolute dependency. Similarly, if 'a' recommends 'b' and 'b' recommends 'c', but 'c' conflicts with 'x', then only 'b' is installed. I will create a test for this issue that covers each of these cases.

Originally reported by ericaustinyu, Jul 17, 2015
-----------------------------------------------------------------------------
Comment 1 Alejandro del Castillo 2017-03-27 22:51:44 UTC
This issue is no longer internalsolver specific. With change 90220245149a2cf753a33a1ff54683b20e7b627e, the was added (libsolv). A side effect is that case broke.

There is an ongoing discussion on https://github.com/openSUSE/libsolv/issues/63 to fix https://github.com/openSUSE/libsolv/issues/63.
Comment 2 Alejandro del Castillo 2017-10-10 16:42:52 UTC
this is fixed on libsolv > 0.6.27
Comment 3 Alejandro del Castillo 2018-12-20 23:34:24 UTC
De-prioritzing internalsolv bugs