Bug 1711216 - Mock on RHEL 8 fails on ".module" named components
Summary: Mock on RHEL 8 fails on ".module" named components
Status: CLOSED DUPLICATE of bug 1756681
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: mock
Version: epel7
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Fedora Extras Quality Assurance
: 1711217 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2019-05-17 08:50 UTC by Nico Kadel-Garcia
Modified: 2019-10-03 12:16 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-10-03 09:04:17 UTC

Attachments (Terms of Use)

Description Nico Kadel-Garcia 2019-05-17 08:50:03 UTC
Description of problem:

Mock fails on RHEL 8 due to ".module+el8" components inconsistent publication and handling

Version-Release number of selected component (if applicable):

mock 1.4.13, RHEL 8

How reproducible:

Install mock from tdawson.fedorapeople.org on RHEL 8, with local eposyync repositories of RHEL 8 Run "mock -r rhel-8-x86_64.cfg install perl-Archive"

Steps to Reproduce:
1. Install reposyinc copy of RHEL 8
2. Install mock from https://tdawson.fedorapeople.org/epel8/orhter/
3. Set up epel-8-x86_64.cfg to use local repos
4. mock -r epel-8-x86_64 install perl-Archive

Actual results:

Fails on failed resolution between perl-libs and perl-libs with "module" release name. Error messages include sugfestions about activationg "--no-best" or "

Expected results:

Expect it to install.

Additional info:

The new "module" based names are going to require distinct settings for mock, to allow resolutions among identical SRPM's built with different manual "dist" settings.

Comment 1 Miroslav Suchý 2019-05-17 09:05:12 UTC
*** Bug 1711217 has been marked as a duplicate of this bug. ***

Comment 2 Miroslav Suchý 2019-05-17 09:14:34 UTC
For the record - the url in step 2 is https://tdawson.fedorapeople.org/epel8/other/

There is no epel-8-x86_64.cfg in Mock, where do you get it? I do not see it on Troy page neither.

BTW if the repository contains modules, then it have to have modulemd file and then Yum will treat it as module and mask the presence of the files. You must explicitely enable the modules using

 yum module enable
 yum module install

I Mock config you can enable/install it using:

config_opts['module_enable'] = []
config_opts['module_install'] = []

Comment 3 Nico Kadel-Garcia 2019-05-17 12:19:12 UTC
Thank you for correcting the URL.

I've published a copy of the "rhel-8-x86_64.cfg" file I'm using, at https://github.com/nkadel/nkadel-rsync-scripts/blob/master/rhel-8-x86_64.cfg It relies on a copy of tdawson's RHEL 8 beta tools, and local reposync download of all the RHEL 8 channels. My script that I use for the reposync is published at https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel-8.sh

The easy fix I've found is to set "best-0" in the .cfg file. This allows dnf to resolve the dependencies without demanding the "best" matches. It's easy to generate with that .cfg file and local RHEL repos by using this command.

    mock -r rhel-8-x86_64.cfg install perl-Archive-Tar perl-Test-Simple

Both of those are required for Samba, and I publish ports of Samba with the the full domain controller features enabled for RHEL and CentOS use. That's how I found this. The generated error logs are fairly bulky, I can copy them in if you like.

Comment 4 Nico Kadel-Garcia 2019-05-17 14:31:11 UTC
That value should read "best=0", not "best-0". Sorry about that, I'm using a new keyboard.

Comment 5 Miroslav Suchý 2019-10-03 09:04:17 UTC
I believe this is duplicate of bug 1756681. Should be fixed in next version of RHEL.

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

Comment 6 Nico Kadel-Garcia 2019-10-03 12:16:40 UTC
Similar problem. This is going to be a recurring problem since the introduction of modules, which are being profoundly mishandled in RHEL 8 with the multiple streams. Setting "best=0" is going to be the only reliable fix in RHEL 8 and CentOS 8, which is suffering the same issue.

Note You need to log in before you can comment on or make changes to this bug.