Bug 1678911

Summary:	dnf builddep cannot evaluate correctly with modules
Product:	Red Hat Enterprise Linux 8	Reporter:	Petr Menšík <pemensik>
Component:	dnf-plugins-core	Assignee:	Jaroslav Mracek <jmracek>
Status:	CLOSED DUPLICATE	QA Contact:	Karel Srot <ksrot>
Severity:	high	Docs Contact:
Priority:	medium
Version:	8.0	CC:	dmach, james.antill, jmracek, ksrot, m.a.young, ngompa13
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-03-26 21:33:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1681085
Bug Blocks:

Description Petr Menšík 2019-02-19 21:13:49 UTC

Description of problem:
We found new issue when running test

Version-Release number of selected component (if applicable):
dnf-plugins-core-4.0.2.2-3.el8.noarch

How reproducible:
always

Steps to Reproduce:
1. enable buildroot repository
2. dnf builddep bind
3.

Actual results:
# dnf builddep bind
Failed to set locale, defaulting to C
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Repository beaker-client-testing is listed more than once in the configuration
enabling rhel-source repository
enabling rhel-AppStream-source repository
enabling rhel-buildroot-source repository
Last metadata expiration check: 0:52:29 ago on Tue Feb 19 15:09:07 2019.
Package gcc-8.2.1-3.5.el8.x86_64 is already installed.
Package systemd-239-11.el8.x86_64 is already installed.
Package pkgconf-pkg-config-1.4.2-1.el8.x86_64 is already installed.
Package make-1:4.2.1-9.el8.x86_64 is already installed.
Package findutils-1:4.6.0-20.el8.x86_64 is already installed.
Package libxslt-1.1.32-3.el8.x86_64 is already installed.
Package sed-4.5-1.el8.x86_64 is already installed.
Package python3-ply-3.9-7.el8.noarch is already installed.
Error:
Problem: cannot install the best candidate for the job
- package softhsm-2.4.0-2.module+el8+2555+b334d87b.x86_64 is excluded
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Expected results:
like when --nobest option is passed, would choose
softhsm-2.4.0-1.el8.x86_64

Additional info:
When dnf module install idm:DL1 is executed, conflicts are solved.

I think packages from modules should not be taken into consideration in builddep, unless that module is installed. bind package does not require idm at all, it requires just softhsm. Version softhsm-2.4.0-1.el8.x86_64 would be sufficient, but higher from module is chosen. But cannot be satisfied short after that.

This issue breaks tests/bind/Sanity/Run-internal-BIND-test-suite test case.

Can be reproduced by:
rhpkg clone tests/bind --anonymous
cd bind/Sanity/Run-internal-BIND-test-suite/
1minutetip --buildroot rhel8

Comment 1 Jaroslav Mracek 2019-02-23 20:38:53 UTC

I create a pull request https://github.com/openSUSE/libsolv/pull/301 that change a logic for identification of a best candidate.

Comment 2 Jaroslav Mracek 2019-02-26 21:56:55 UTC

The patch was rejected by upstream

Comment 4 Karel Srot 2019-03-26 14:07:04 UTC

I believe this is duplicate to bug 1677583. dnf builddep utilizes packages from the non-active stream. 

Anyway, builddep cannot behave (in terms of depsolving) differently than dnf itself, that doesn't make sense. If there is an active (default/enabled) modular content then it should be fetched by builddep. Not doing so would be very confusing to users and potentially disruptive for the system maintenance.

@Jardo,
can we close this one as duplicate?

Comment 5 Jaroslav Mracek 2019-03-26 21:33:20 UTC

Builddep as well group conditional packages use a different transaction formation.

*** This bug has been marked as a duplicate of bug 1677583 ***

Comment 6 Karel Srot 2019-03-27 07:06:08 UTC

(In reply to Karel Srot from comment #4)
> Anyway, builddep cannot behave (in terms of depsolving) differently than dnf
> itself, that doesn't make sense. If there is an active (default/enabled)
> modular content then it should be fetched by builddep. Not doing so would be
> very confusing to users and potentially disruptive for the system
> maintenance.

Just to clarify, the above was the reaction to the proposal from #c0
> I think packages from modules should not be taken into consideration in builddep