Red Hat Bugzilla – Bug 843745
[RFE] Add support for automatically downloading, building and installing dependencies in the chroot
Last modified: 2017-08-22 16:40:21 EDT
Created attachment 600720 [details]
Patch to add --megadeps command
The recently added mockchain script works by creating a local RPM repo and successively creating and destroying mock chroots until all SRPMs are building correctly. This can be quite slow if you have a lot of dependencies, and also requires determining the dependency list beforehand
The attached patch takes a different approach, allowing the mock configuration to include SRPM sources in addition to binary RPM sources and adding a new "--megadeps" command that works roughly as a combination of "--rebuild" and "--installdeps".
If a binary dependency is found to be missing, the "--megadeps" command means that mock will try to download the source RPM and build and install that, including the created RPM in the build result.
This mean that when migrating a large application with a lot of non-RHEL dependencies (e.g. Bugzilla) between RHEL versions without the aid of a centralised build tool like koji, you can simply define suitable sources of SRPMs (e.g. EPEL, versions of Fedora of similar vintage to the target RHEL version) and run a command like:
mock -r <chroot config> --megadeps <application SRPM>
While this is useful in its own right, many dynamic language applications also depend directly on components from the language specific resources like CPAN. The attached patch includes an additional piece of CPAN integration that automatically generates an SRPM with cpanspec if no preexisting binary RPM or SRPM is available in the configured yum repos. That part may be better extracted and considered as a separate patch to the base feature of automatic building of dependencies.
The attached patch works (and has been used to ease RHEL 5 to RHEL 6 migrations), but can sometimes be thrown off if yum emits unexpected error messages (e.g. due to broken repos).
FYI this patch is now being carried in github.
Personally I am ambivalent about this patch.
1) I do not like having it in mock itself, because if I am reading code correctly it would mean that rebuilt deps would not have clean chroot.
2) I like this logic and I would like to have this in mockchain. Much rather then current logic, which is there.