A new option `--buildroot-image=` similar to `bootstrap_image`

[praiskup]

As the --use-bootstrap-image feature is now stabilized, and enabled by default (mock v5.0+), we can start thinking about a similar feature for the build chroot (buildroot) itself.

Buildroot preparation is relatively expensive and time consuming task because installing the (dynamic) build dependencies generates many DNF transactions, and downloads huge pile of DNF/RPM (meta)data.

I'd propose to have two new options (this is to replicate the naming option from bootstrap_image, bootstrap_image_ready and use_bootstrap_image).

• buildroot_image - string pointing at a downloadable container image, it would be used for the initial buildroot preparation
• buildroot_image_ready - if specified, no DNF operations will be done, and the rpmbuild process will just fail on missing deps if something is really missing
• use_bootstrap_image - triggers the use of the buildroot_image

The problem with the buildroot_image option (contrary to bootstrap_image) is that we can not simply have a reasonable default for everyone and every package out there; each package - on each distribution - has a different build dependency set. Therefore this would be completely up to the end user to provide such an image, and eventually use it via --buildroot-image=my-mock-specific-buildroot. This new commandline option should set:

• buildroot_image=my-mock-specific-buildroot
• use_bootstrap_image=True
• buildroot_image_ready=True
• use_bootstrap=False - not we don't need to generate bootstrap at all

So, with the new --buildroot-image option, mock would just extract the buildroot image into a directory, do necessary (but very fast) directory modifications, and directly start rpmbuild.

Things to do:

• [ ] forcearch and image downloads - see #1110 which for buildroot (not bootstrap) is not going to be that easy

[praiskup]

@ericcurtin @odra CC

What do you folk think about this proposal, especially WRT to the pkgbox? Would you be able to cooperate on the feature here?

With https://github.com/kubernetes/kubernetes/pull/116377 in OpenShift, we can run Mock "rootless" easily (root in a separate user namespace). Therefore, Mock is going to be a normal thing in OpenShift soon. This feature seems like a low-hanging fruit and has the potential to minimize the buildroot preparation time to almost zero.

[Conan-Kudo]

What about being able to take rootfs images in disk image or plain tarball formats?

[praiskup]

That would make sense as well, I think we have to start with something (we already have the Podman image download support in Mock, so it is the easy starter). But downloading root_cache tarballs, rootfs images, disk images or whatever else seems like a trivial alternative. Would that affect the proposed option/cmdline API?

[voxik]

I am not huge fan of this RFE, mainly due to the additional complexity.

BTW this RFE reminds me this discussion:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TA3KCIYA7UDZYCP6IRH6LLMCBKUTJAUN/ https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OCKSM7B7VKUK4QBC6UNRXJ4CAWO6WG63/

[praiskup]

I am not huge fan of this RFE, mainly due to the additional complexity.

This will bring some new opt-in if-else branches, yes. But nothing exceptional? I replied dozens of times to questions related to this. People typically start with

1. Containerfile: FROM fedora:XYZ
2. Containerfile: RUN dnf install -y x y z
3. Containerfile: USER abc
4. podman run ... rpmbuild... srpm/spec

To a random observer, appears to be as easy as that, making the 1-3 steps super fast for repeated runs (and easily shareable). Except that this is a re-implementation of Mock. Is it good for Koji? Probably not.

[Tojaj]

Disclaimer: This is very unlikely to happen

IMHO, this would be awesome if it works in tandem with Koji itself - i.e. Koji generates these buildroot container images from the buildroot content.

Something like this:

• A koji admin/releng would enable a buildroot container generation directly on the buildroot tag (i.e. it wouldn't be enabled by default for every buildroot - admin/releng would enabled it only for these buildroots where it matters).
• This enablement would be tracked as another option in "Tag options" that define various params for the buildroot (e.g. some mock options) - just see koji taginfo $SOMEBUILDROOT.
• Koji would built a "base buildroot container" from that buildroot tag (this would likely require a koji admin or releng to prepare a Dockerfile for that particular buildroot container and store it somewhere where koji can use it as I don't think a some universal Dockerfile could be used).
• The "base buildroot container" would have pre-installed the list of packages that are pre-installed for each build in that build tag (buildroot) i.e. packages from srpm-build and build groups of that buildroot - see koji list-groups $SOMEBUILDROOT.
• That image would be automatically re-build by Koji every time a package included in the image is updated in the buildroot tag. (Likely by Kojira - the deamon that periodically regenerates buildroot repos when change in content is detected)
• These images would be available in a predefined registry used by that koji instance so mock knows how to find them.

This way this would work out-of-box for mock and users regardless if it's a user who runs mock locally or Koji itself who runs it as part of RPM build. Mock would just auto-detect that Koji has a buildroot container available for the buildroot and download it - instead of bootstraping the whole chroot structure from scratch by downloading the packages and installing them.