Bug 1256011 - mock w/ dnf produces different builds than mock w/ yum
mock w/ dnf produces different builds than mock w/ yum
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mock (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Suchý
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-23 04:33 EDT by Ralf Corsepius
Modified: 2015-10-07 00:06 EDT (History)
7 users (show)

See Also:
Fixed In Version: 1.2.13-2.fc22 mock-1.2.13-2.fc21 mock-1.2.13-2.el7 mock-1.2.13-2.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-23 00:10:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2015-08-23 04:33:06 EDT
Description of problem:

mock w/ dnf underneath produces different build results than mock w/ yum.

Version-Release number of selected component (if applicable):
mock-1.2.12-1.fc22.noarch

How reproducible:
Always

Steps to Reproduce:
1. rebuild edac-utils-0.16-11.fc22.src.rpm in 
   fedora-rawhide-x86_64 chroots on fc22
and
   scratch-build it on fedora-rawhide builders.

Actual results:
Local builds succeed - Scratch-builds or real builds fail.
cf. 
https://bugzilla.redhat.com/show_bug.cgi?id=1239443
and
http://koji.fedoraproject.org/koji/taskinfo?taskID=10792918

Setting config_opts['package_manager'] = 'yum' in 
/etc/mock/fedora-rawhide-x86_64.cfg
could reproduce the FTBFS.

Expected results:
Deterministic builds. I.e. using the same package-installer in both, the builders and local mocks.

ATM, this would mean to revert to using yum in local mocks.
Comment 1 Miroslav Suchý 2015-08-24 05:58:41 EDT
Three problems here:

1) The fact that the build succeed with DNF and not with YUM is because with yum, there is not installed "systemd" package and therefore %{_unitdir} is not defined (only systemd-libs is installed). Currently released mock install soft dependeces as well and will install "systemd". This was reported in bug 1254634 where I put
  install_weak_deps=0
in 
  etc/mock/fedora-23-x86_64.cfg
in main section of config_opts['yum.conf']
After this change Mock with DNF fails to build it as well, because "systemd" is not installed too.

2) This is not problem of mock itself. Different depsolving means potentially different results. Only real problem was installing soft deps, which should not be needed for building and this was already addressed in bug 1254634.

3) So only real problem is that @buildsys-build group does not include package which define macro %{_unitdir}. I beleive that it is bug of edac-utils which should add "systemd" to build requires.

*** This bug has been marked as a duplicate of bug 1254634 ***
Comment 2 Ralf Corsepius 2015-08-24 06:22:24 EDT
Reopening.

Understood - You missed the core of this BZ:

RFE: Change mock's configurations to use yum until the official builders start using dnfs, because the current mock configurations produce different build results than the official builders.
Comment 3 Miroslav Suchý 2015-08-25 02:19:51 EDT
My immediate reaction was WONTFIX. The move to DNF in mock and Koji was agreed on long time ago. The fact that mock moved to DNF before Koji allowed us to discover several issues in mock, DNF and even in Koji before it would hit wider audience.

However it seems that Koji will not meet the deadline and final F23 will not be build by DNF in Koji. If that happen I will revert F23 targets back to yum so Mock is on pair with Koji.
However future targets (F24+, rawhide) will stay with DNF.
Comment 4 Richard Fearn 2015-08-25 06:47:41 EDT
I really think you should change mock to use yum instead of dnf.

One of my packages (findbugs-contrib) depends on "jsp", and during compilation its Ant build script expects to find the JSP API JAR in /usr/share/java/jsp.jar.

With yum, "jsp" is provided by tomcat-jsp-2.3-api, which (using alternatives) creates the jsp.jar symlink in /usr/share/java.

With dnf, "jsp" is provided by glassfish-jsp-api, which doesn't provide /usr/share/java/jsp.jar.

So:

* Koji build → uses yum → succeeds
* Local mock build → uses dnf → fails
* Local mock build using yum → succeeds

mock has the --yum option, but as far as I can tell `fedpkg mockbuild` does not. So the only way to get local mock builds that are consistent with Koji builds is to manually edit the files in /etc/mock.

I guess there could be two views on what mock is:

1. A general-purpose tool for building RPMs in a chroot.
2. A tool for Fedora packagers to build their packages locally.

For the first use case, sure, it makes sense to be using dnf instead of yum - yum is deprecated, dnf is now the default package manager on Fedora, so yes, mock should be using dnf instead of yum.

For the second use case, however, Fedora packagers want mock to behave in the same way as Koji. Having local builds behave differently to 'official' builds with Koji is very, very confusing.

(You could argue that findbugs-contrib should build with either copy of the JSP API JAR. But this isn't about what specific packages should or shouldn't do; this is about having consistency between local and Koji builds for Fedora packagers.)
Comment 5 Miroslav Suchý 2015-08-25 07:56:45 EDT
Koji team is hard working to move to use DNF. They are still waiting for some packages to get into Fedora stable. AFAIK this is only blocker.
If there would be no issues, Koji would already use DNF today.
I really hope they do the switch in few day.

So this inconsistency are only for short transient period. And mock had to move first and Koji follows. Simply because Koji use Mock and not in reverse.

The move to DNF is inevitable. So you should solve this build errors on packaging level anyway.
Comment 6 Miroslav Suchý 2015-09-08 10:43:49 EDT
I reverted F23 configs back to yum per
  https://lists.fedoraproject.org/pipermail/buildsys/2015-September/004862.html

Rawhide builds continue to use DNF because this is what is anticipated to be used in Koji in near future.
Comment 7 Fedora Update System 2015-09-16 16:01:53 EDT
mock-1.2.13-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16053
Comment 8 Fedora Update System 2015-09-16 16:04:52 EDT
mock-1.2.13-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16054
Comment 9 Fedora Update System 2015-09-16 16:06:51 EDT
mock-1.2.13-2.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16056
Comment 10 Fedora Update System 2015-09-16 16:08:35 EDT
mock-1.2.13-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8114
Comment 11 Fedora Update System 2015-09-16 16:09:41 EDT
mock-1.2.13-2.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8115
Comment 12 Fedora Update System 2015-09-17 17:30:03 EDT
mock-1.2.13-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update mock'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16054
Comment 13 Fedora Update System 2015-09-18 01:20:58 EDT
mock-1.2.13-2.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update mock'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16056
Comment 14 Fedora Update System 2015-09-18 12:24:48 EDT
mock-1.2.13-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update mock'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16053
Comment 15 Fedora Update System 2015-09-18 23:19:53 EDT
mock-1.2.13-2.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update mock'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8115
Comment 16 Fedora Update System 2015-09-18 23:21:43 EDT
mock-1.2.13-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update mock'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8114
Comment 17 Fedora Update System 2015-09-23 00:09:22 EDT
mock-1.2.13-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2015-09-24 04:23:23 EDT
mock-1.2.13-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 19 Fedora Update System 2015-10-05 18:50:31 EDT
mock-1.2.13-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Comment 20 Fedora Update System 2015-10-06 23:05:01 EDT
mock-1.2.13-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2015-10-07 00:04:47 EDT
mock-1.2.13-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.

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