Supporting EPEL Builds in Koji
Using Koji to build EPEL packages has been a goal for a long time. However, it has been held up by the desire to build against official RHEL packages while not making those packages public. Right now Koji can only build against packages it has a local copy of, under /mnt/koji/packages, and that directory is served via http to the public.
This is a proposal to enable Koji to populate the minimal buildroot and resolve dependencies using packages from an admin-configurable remote yum repository. A minimum amount of information about packages from the remote repository would be inserted into the local Koji database to allow the package to be traced back to its origin. This would enable Koji to pull RHEL packages from a private repo for the purpose of building EPEL packages, without making the RHEL packages public. Note that everything built by Koji would still be available to the public. This approach has the additional benefit of greatly simplifying the bootstrapping process for people running their own Koji instances. They can simply consume packages from an existing yum repo and skip the entire package import process.
Implementation
Finding the packages
Koji generates a yum config for every buildroot it creates and uses. This config currently points to a single repo that has been created by Koji from packages associated with the build tag. To enable the use of a remote repo, a second repo will be added to this yum config. A new field, remote_repo_url will be added to the tag_config table in the Koji database to hold the URL of the additional repo, configurable on a per-tag basis. Priorities in the yum config will be setup such that if a package exists in both the local Koji environment and the remote repo, it will be pulled from the local environment, even if it's an older version. This will provide an admin with maximum control over the Koji buildroot contents, and the ability to upgrade or downgrade packages as necessary. This may require the yum-priorities plugin to be installed on the build hosts.
Tracking packages
When a build is complete Koji uploads the list of packages in the buildroot to the hub to be inserted into the database for tracking purposes. Currently, every package in the list must exist in the Koji database or an error will be raised. Under this proposal, if the remote repo in the tag_config table is null, this behaviour doesn't change, and Koji will work exactly as it does now.
NOT YET COMPLETE