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), or
> 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 dnf
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
While it is less likely, I'm afraid that similar problems may happen with
microdnf too (microdnf still depends on some libraries). So perhaps we we
shouldn't install packages from the side-tag into the bootstrap?
Also note there's --use-bootstrap-image option that could help here.
But I got around that with:
config_opts['root'] = 'fedora-rawhide-microdnf'
config_opts['package_manager'] = 'microdnf'
config_opts['microdnf_command'] = '/usr/bin/microdnf'
config_opts['microdnf_install_command'] = 'dnf-install microdnf
config_opts['system_dnf_command'] = '/usr/bin/dnf'
config_opts['microdnf_common_opts'] = ['--allowerasing']
However, it still ends with:
Curl error (37): Couldn't read a file:// file for
[Couldn't open file
Running `mock -r fedora-rawhide-microdnf --init` twice works around that
problem, and it successfully crates the boostraop chroot, but then, trying to
create the actual one, it fails with:
Start: microdnf install
Directory /var/lib/mock/fedora-rawhide-microdnf/root doesn't look like it has an
OS tree. Refusing.
buildsys mailing list -- buildsys(a)lists.fedoraproject.org
To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines