Bug 1118719 - [RFE] Use of different version of RPM than the system one
Summary: [RFE] Use of different version of RPM than the system one
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Fedora Extras Quality Assurance
: 1425446 (view as bug list)
Depends On:
Blocks: 1426531
TreeView+ depends on / blocked
Reported: 2014-07-11 10:56 UTC by Vít Ondruch
Modified: 2018-02-22 15:46 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2018-02-22 15:46:42 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1447627 None NEW mock --installdeps or --install can't find rpm to install with --bootstrap-chroot 2019-05-01 08:29:58 UTC

Internal Links: 1447627

Description Vít Ondruch 2014-07-11 10:56:14 UTC
This is probably too far fetched, but I'd like to discuss possibility of use of different version of RPM then the default system one. Here is the use case:

We are building package for Fedora using Mock. Mock in turn is using Yum/Dnf with --buildroot parameter, to specify the root location. However, the not so pleasant limitation of Dnf/Yum is, that the buildroot is prepared by current system version of RPM. If it were be possible to use RPM version from the buildroot which is going to be prepared, it would allow faster adoption of new RPM features.

Comment 1 Ales Kozumplik 2014-07-11 11:17:55 UTC
Hi Vit,

This has few technical problems which price of overcoming can not be justified by 'faster adoption of new RPM features'. What is the real use case you are after then?

Comment 2 Vít Ondruch 2014-07-11 11:36:19 UTC
Yes, I understand that it might not be simple.

Traditionally, Fedora builders were hosted on RHEL6, so that meant that RPM used to prepare build root was rather old. Although now the builders are hosted on F20 to my knowledge, still, I can't use the latest and brightest features of RPM.

For example, I am not sure if I can use the newly introduced %load macro on Koji, during the SRPM build step.

Actually, this RFE was triggered by recent FPC discussion with regards of SCL, repeating several times that SCL is pile of hacks, which is actually true. And true is also, that we never asked RPM for any modifications, since the RPM used to prepare the buildroot was always older then the RPM which features we would like to use.

So to say, I probably don't have any better/specific usecase at my hand ATM, but I have to ask, since everybody else probably trashed this idea even before asking :)

Comment 3 Ales Kozumplik 2014-07-11 11:39:09 UTC
OK, thank you for a more elaborate description, we'll see what we can do.

Comment 4 Vít Ondruch 2014-07-11 13:01:41 UTC
Thanks. I am decreasing the priority if that makes any difference :)

Comment 5 Florian Festi 2014-07-16 15:04:07 UTC
This request is not too far fetched and pretty reasonable. Having a more recent version of yum/dnf/rpm on the builders would be a great thing.

But this has do be done on the builders and cannot be solved by the dnf (or any other of the above) component(s). Reassigning to "distribution" as the proper solution needs to be tightly integrated with the build system. There are several possible solutions for this problems and only rel-eng has a chance of figuring out with is actually going to work and if it is really worth the hassle.


Comment 6 Vít Ondruch 2014-07-16 15:33:06 UTC
(In reply to Florian Festi from comment #5)
Actually, you are right that solving this on "distribution" level is also one possibility. On the other hand, I feel it makes it somehow harder for me as a packager, since if I can speculate about what you meant by "several possible solutions for this", this would require updated version of RPM on builders, which differs from the standard version of RPM I have available on my system by default.

Could you please elaborate more about this?

Comment 7 Dennis Gilmore 2014-07-16 16:00:58 UTC
builders are currently Fedora 20 and will be moved to Fedora 21 when it is stable. I think this is more about being able to have a newer rpm on the local machine? not really sure though as its all a bit vague and handwavy.

Comment 8 Vít Ondruch 2014-07-17 05:19:19 UTC
The point is:

*As soon as new tool from RPM/DNF/YUM chain is available, we should be able to use its features ASAP*

Since mock buildroots are prepared by RPM/DNF/YUM from the builders, we are lagging behind. We should be able to use Rawhide's RPM/DNF/YUM instead.

May be we need something like mock in mock? The first level build root would be prepared by current system RPM/DNF/YUM and it would contain Rawhide versions of the same set of packages. This first level buildroot in turn would be used to create the second level mock build root, as we know it today.

Since there is now ongoing some development on Mock, I'm adding Mikolaj on CC. May be he can have some interesting ideas as well.

Comment 9 Mikolaj Izdebski 2014-07-17 06:00:01 UTC
The problem could be solved in several ways.

1) An SCL containing latest mock with latest dependencies like RPM and DNF.  It shouldn't be to hard to make them available even on RHEL 6, if needed.

2) Chroot with minimal rawhide installation containing mock with deps. The chroot could be maintained with system mock, resulting it two or more layers of nested mocks.

3) It should be easy to make paths to rpm and dnf configurable in mock, so that it could use newer versions of these tools, for example from user's $HOME. I personally did that a few days ago when I was trying to use latest upstream RPM, which has the ability to generate weak auto-requires, but is not yet in Fedora, not even in rawhide. I solved this by compiling RPM myself and pointing mock to it.

Michael, could you make rpm/dnf paths configurable in mock config? Additionally please make room for specifying custom args to these tools. (Example use case: Passing --rpmfcdebug to rpmbuild as a nice way of debugging auto-requires generators.) I opened issue for this: https://github.com/msimacek/mock/issues/7

Comment 10 Miroslav Suchý 2015-10-09 09:49:59 UTC
I think this is something what can be done in Mock. Therefore switching component to mock.

Comment 11 Miroslav Suchý 2017-02-21 15:32:25 UTC
*** Bug 1425446 has been marked as a duplicate of this bug. ***

Comment 12 Igor Gnatenko 2017-02-24 09:24:14 UTC
This makes impossible to have new features in RPM (in rawhide) and use them from Fedora because koji builders use stable fedora.

Same applies to COPR. If I have patched RPM or dnf, it won't use it, hence build will fail.

Comment 13 Panu Matilainen 2017-02-24 09:38:09 UTC
Oh, I wouldn't complain too much about the current situation. In not so distant past, rpm features available to Fedora rawhide were limited to those of latest released RHEL. To us old-timers, being only limited to latest Fedora stable is almost like a life-long dream come true :)

Comment 14 Miroslav Suchý 2017-02-28 17:54:50 UTC
See https://github.com/rpm-software-management/mock/issues/15 for another use case (duplicate of this one).

Comment 15 Michael Cullen 2017-03-01 02:46:56 UTC
I've had a crack at implementing a feature to first build an outer chroot, then use that to assemble the main build chroot - effectively making the chroot built by its own version of yum/dnf


Comment 16 Vít Ondruch 2017-09-05 07:20:24 UTC
@Michael would you mind to look at bug 1447627 to polish this feature a bit?

Comment 17 Michael Cullen 2017-11-23 19:03:56 UTC
Hmm I probably should take a second pass at this :-)

Comment 18 Vít Ondruch 2017-11-24 11:18:36 UTC
Frankly, except the bug 1447627, I am not sure the feature in its current state is usable. The longer I am using it, the more I think it should not be possible to enable it globally, but it should be set per buildroot.

E.g. I am using Fedora Rawhide and I want to build RHEL6 packages. That means I'd like to be able to use Fedora's DNF to setup bootstrap buildroot, which contains YUM. What I really don't want actually is to have YUM installed on my system.

Now the question is where the YUM is coming from, if it is RHEL6 version or Fedora version. Possibly I might choose different one for different reasons.

And we are speaking here just about DNF/YUM from Fedora/RHEL, but if I want to use the bootstrap buildroot for lets say OpenSuse, I probably still want to use Fedora's DNF to setup the bootstrap buildroot, but I want to point it to OpenSuse repositories and install Zypper from there, because Zypper might not be in Fedora (Is it? I don't know. If it is, is it well maintained?).

Comment 19 Miroslav Suchý 2017-12-01 13:08:31 UTC
Well you can have:
config_opts['bootstrap_package_manager'] = 'dnf'
config_opts['package_manager'] = 'zypper'

and if you implement the functionality of zypper package manager (just few lines)
then bootstrap will be installed using dnf and target chroot using zypper from the bootstrap chroot (i.e. the suse version).

Comment 20 Vít Ondruch 2017-12-01 13:49:40 UTC
(In reply to Miroslav Suchý from comment #19)
> Well you can have:
> config_opts['bootstrap_package_manager'] = 'dnf'
> config_opts['package_manager'] = 'zypper'
> and if you implement the functionality of zypper package manager (just few
> lines)
> then bootstrap will be installed using dnf and target chroot using zypper
> from the bootstrap chroot (i.e. the suse version).

Nice, but this does not answer if DNF is installing Zypper from Fedora or Suse repositories.

Comment 21 Miroslav Suchý 2017-12-04 10:54:23 UTC
In this situation Mock would install Zypper from Suse (because it will use repository specified in mock config). First it will install it into bootstrap chroot using host's DNF, then it will install target chroot using the Zypper. But in both situation it will use suse repository.

Comment 22 Vít Ondruch 2017-12-12 10:52:35 UTC
Ok, this is too artificial discussion. Here is real situation. I am using Fedora Rawhide and I don't have YUM installed, since I don't need it for anything. But I want to build package for EPEL. Here are the changes to the config file I did:

# diff /etc/mock/epel-7-x86_64.cfg{.orig,} -u
--- /etc/mock/epel-7-x86_64.cfg.orig	2017-12-12 10:15:46.788617613 +0100
+++ /etc/mock/epel-7-x86_64.cfg	2017-12-12 10:16:57.062265280 +0100
@@ -5,6 +5,11 @@
 config_opts['dist'] = 'el7'  # only useful for --resultdir variable subst
 config_opts['releasever'] = '7'
+config_opts['use_bootstrap_container'] = True
+config_opts['bootstrap_package_manager'] = 'dnf'
+config_opts['package_manager'] = 'yum'
 config_opts['yum.conf'] = """

And this is mock output:

$ mock -r epel-7-x86_64 --init
INFO: mock.py version 1.4.7 starting (python version = 3.6.3)...
ERROR: Command /usr/bin/yum is not available. Either install package containing this command
or run mock with --yum or --dnf to overwrite config value. However this may
lead to different dependency solving!
Traceback (most recent call last):
  File "/usr/libexec/mock/mock", line 949, in <module>
  File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py", line 96, in trace
    result = func(*args, **kw)
  File "/usr/libexec/mock/mock", line 706, in main
  File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py", line 96, in trace
    result = func(*args, **kw)
  File "/usr/lib/python3.6/site-packages/mockbuild/buildroot.py", line 62, in __init__
    self.pkg_manager = package_manager(config, self, plugins, bootstrap_buildroot)
  File "/usr/lib/python3.6/site-packages/mockbuild/package_manager.py", line 21, in package_manager
    return Yum(config_opts, chroot, plugins, bootstrap_buildroot)
  File "/usr/lib/python3.6/site-packages/mockbuild/package_manager.py", line 191, in __init__
  File "/usr/lib/python3.6/site-packages/mockbuild/package_manager.py", line 171, in _check_command
    lead to different dependency solving!""".format(self.command))
Exception: Command /usr/bin/yum is not available. Either install package containing this command
or run mock with --yum or --dnf to overwrite config value. However this may
lead to different dependency solving!

Comment 23 Miroslav Suchý 2018-02-22 15:46:42 UTC
I am closing this RFE as done. We have the bootstrap feature. Yes, it has issues. But address them one by one. The problem in #22 seems to be dupe of bug 1467314, so lets continue there.

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