On 11/30/20 10:14 AM, Pavel Raiskup wrote:
On Sunday, November 29, 2020 1:44:37 AM CET Miro Hrončok wrote:
> On 11/29/20 1:28 AM, Miro Hrončok wrote:
>> I was wondering whether it might be possible to use microdnf instead of dnf in
>> the boostrap mock chroots. Since dnf depends on Python, using the boostrap mode
>> now complicates upgrading Pythons to a newer version.
>> Basically, if/when Koji uses the bootstrap mock mode, as soon as we start
>> bootstrapping (different meaning) Python in a side tag, dnf becomes temporarily
>> uninstallable in that side tag and we can no longer do any builds.
>> This can be worked around by not using the boostrap mock option in Koji (ideally
>> only for Python upgrade side tags, but I am not yet sure if that's possible),
>> by eliminating Python libraries out of the bootstrap chroot, hence the idea
>> about using microdnf.
>> I've started with this config:
>> config_opts['root'] = 'fedora-rawhide-microdnf'
>> config_opts['package_manager'] = 'dnf'
>> config_opts['dnf_command'] = '/usr/bin/microdnf'
>> config_opts['dnf_install_command'] = 'install microdnf'
>> config_opts['system_dnf_command'] = '/usr/bin/dnf'
>> config_opts['dnf_common_opts'] = ['--allowerasing']
>> But it fails pretty soon with:
>> error: (--setopt) Unknown tsflag: nocontexts
>> And when I patch that option out, I still get:
>> error: The "--installroot" argument must be used together with
>> "--noplugins", "--setopt=cachedir=<path>",
>> "--setopt=varsdir=<path>" arguments.
>> But I guess that if I figure the right options for dnf_common_opts, this might
>> work...? Is there some crucial functionality that microdnf might be missing that
>> would prevent it from creating mock chroots like this?
> I guess I should have searched a bit better before asking the questiong.
> I found the microdnf option in mock:
> But using config_opts['package_manager'] = 'microdnf' still installs
> the bootstrap chroot, which is confusing.
It is likely we'll have to fix Mock too, dunno. Because of the missing
functionality in microdnf nobody had enough motivation to spend more time
on the microdnf support in mock so far.
I'm just not sure it is a valid use-case to fall-back to microdnf in this
case. The point of bootstrap was to install the final chroot by the
**default** tooling from that chroot. Not only to absorb the "RPM"
differences (like sqlite vs BD) but also to stop playing with
the small nuances between 'yum' in RHEL vs. 'yum' in Fedora, or even
'dnf' in F33 vs. 'dnf' in F31.
Going with microdnf is a bit against that principle. At least as long as
microdnf isn't guaranteed to e.g. calculate 100% compatible transactions
with DNF, or as long as 'microdnf' is not the default Mock installer for
That makes perfect sense.
While it is less likely, I'm afraid that similar problems may
microdnf too (microdnf still depends on some libraries).
While technically yes, it's easier to manage around a single C library bootstrap
than around dozen of Python packages with many more build dependencies.
So perhaps we we
shouldn't install packages from the side-tag into the bootstrap?
Yes, that would be ideal.
Also note there's --use-bootstrap-image option that could help
Do you think we could use that in Koji?