Miroslav Suchý

What is COPR

I have recently joined Slavek Kabrda (bkabrda) and Seth Vidal in COPR project. You never heard of COPR before? COPR should be an equivalent of PPA for Fedora. The whole idea started in 2010, but the coding actually started late in 2012. And what we have right now is functional prototype (log in is restricted to few testers right now due lack of disc space).

Current COPR is very simple: it accepts URL of src.rpm (it is your responsibility to upload it somewhere), puts it in queue and starts a virtual machine from Fedora Cloud. That VM builds just that one particular package and then is terminated. Results are put into project directory and yum repo is created.

But in July several things changed: Seth died and Slávek backed down dur to other duties. On the other hand I joined.

As I joined the project I was curious what are the requirements? And it appeared that they have changed as well.

So beside providing simple PPA equivalent we want:

• to provide build system for upstream of layered projects (e.g. OpenShift, Katello, SoftwareCollections) as well as development/testing space for various SIGs
• to provide build system for projects which are not yet part of Fedora (i.e. Ring 3 from Fedora.Next)
• to provide personal repositories (and even private) for tests before merging into Rawhide or RHEL/CentOS.
• to provide space&infrastructure for automated rebuilds of upstream packages

Which means that:

• we want better team cooperation - allow more users to work on one project
• ability to create branches and custom repos (-testing, -updates etc)
• we want better monitoring of jobs - see where your build succeeded, where it failed and why.
• ability to automatically trigger rebuilds if one depended package changes

This means that what was meant to be light-weight build system will not be light any more. So I made step back and did investigation whether:

1. we should continue to develop another build system from scratch, which will be different from everything else (copr currently uses very little from our existing tooling)
2. use current COPR, but merge the backend code into Koji and use Koji as backend for COPR.
3. start using Open Build Service.

Option one IMHO does not make sense. With only one man dedicated to COPR (me), we will have no time to implement features you will likely request. I will have time just for bugfixing and keep that system in work.

So I think real options are only 2 or 3. I've looked closely at both options, did review of OBS and what it currently offers to its users and I will post analysis of those options in next blogpost.