probably not worth the effort at this point. "If it works don't touch it". Test see about this when we try to introduce fc26 in a few months.

Looking at the bug, it seems we may be getting this for "free" though, by just doing "yum update mock".

If we want to give it a try, according to https://bugzilla.redhat.com/show_bug.cgi?id=1405783, it might be possible to use el7.3+dnf+mock now.

This patch resolved the issue for now: https://gerrit.ovirt.org/#/c/69077/

Another solution as I see would be to check the current status of "dnf" in epel, here are some references:

"EL6 and EL7 does not have DNF available (well there is DNF in EPEL7, but not dnf-plugins-core, which are crucial for for Mock)." and in comments there is a reference to some old dnf-plugins-core build:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6436

it might be that everything needed is already in EPEL and this potentially may mean that we can install dnf and everything needed on CentOS7 vms we use and use "dnf" only for Fedora mocks while keeping "yum" for CentOS mocks. Not sure if they can work together and if it is possible to make it work, but this is another direction to explore.

Official information:

https://github.com/rpm-software-management/mock/wiki#mock-on-el-6-and-el-7-yum-and-dnf
http://miroslav.suchy.cz/blog/archives/2015/05/20/why_mock_does_not_work_on_el_6_and_el7_and_how_to_fix_it/index.html

the later says:

"This is something which you may want to do, when you are building some packages for personal usage. However you should avoid that if you are operating some build system. In such case migration to some recent Fedora is your only option." and "Change Mock settings that EL6 and EL7 users will continue to use Yum for building Fedora rawhide (and F23+). While this option seems to be good trade-off, there is big risk that you end up with different binary compared to the same process on Fedoras. For example there was issue that Rubygems requires ruby(release), which Yum resolved to normal ruby, however DNF resolved that to jruby. And that is big difference."

and all the workarounds proposed as I see for the opposite - use yum enabled mocks on fedora.

Upgrading Fedora seems to me standard and supported procedure and business as usual. If we do it manually we can automate it so it scales.

Inserting hacks into "yum" to work with Fedora composes is not standard and not supported. Hence it is not possible to automate and it will always be manual work on its own and thus I do not think it is sustainable solution for future. Especially since we do have Fedora slaves already and have to support them anyway.

This comes with a price - if we'll have more fedora slaves than centos due to this, then we'll need to to mass upgrades much more often, due to the speed of fedora releases goes EOL

I support in that we should not try to maintain non supported options ourselves if we have options.

I would better use fedora executors with dnf for fedora mock jobs. This is part of reality that using yum with FC25 is no longer supported and will never be supported, that mock uses external package management tool to install packages and that there is no dnf in centos7. All this combined means that we cannot normally use Fedora mock on CentOS right now. And since we have Fedora slaves we can run such jobs on Fedora.

We have Fedora slaves attached to the Jenkins and I prepared a few fc25 ones as part of . Maybe we should make fc25 jobs run only on fc25 slaves for now? Does mock itself support dnf?

So we need to think if we can just use 'dnf' in fc25 mock config instead.

We cant. We need it to run on el7 hosts. Those do not have DNF.

As commented in https://bugzilla.redhat.com/show_bug.cgi?id=1360781#c28 , changing the installation to 'dnf' works. So we need to think if we can just use 'dnf' in fc25 mock config instead.

In order words, just implement what already described above