Copr integration

Mike McLean mikem at redhat.com
Fri Oct 11 16:04:46 UTC 2013


There has been a lot of discussion lately about the future of Copr. The
current plan is to integrate Copr with Koji in order to get the features
folks want from Copr in a reasonable timeframe. For background, look here:

https://lists.fedoraproject.org/pipermail/devel/2013-September/188751.html
https://lists.fedoraproject.org/pipermail/devel/2013-August/188575.html
https://lists.fedorahosted.org/pipermail/copr-devel/2013-August/000729.html

The plan is not for a complete merger, but for Copr to remain a separate
project that makes use of Koji. However, this will still require changes
to Koji. These changes will need to be fairly invasive and may be a
little unstable for a while, so I've created a separate fork to track them:

https://github.com/mikem23/copr-koji

(I should probably have just used a branch in our normal upstream, but I
haven't really had a chance to really play around with github and this
seemed like a reasonable excuse)

Some of these changes will be a matter of removing some of the
hard-coded restrictions in Koji that don't necessarily make sense for a
system like Copr.

The first thing I opted to tackle was dealing with Koji's uniqueness
constraints for NVRs and NVRAs. My approach was to add namespaces for
builds. Within a given namespace, NVRs are still required to be unique,
but cross-namespaces conflicts are allowed. Additionally, within the
NULL namespace any number of conflicts are allowed.

Using namespaces allows folks that want NVR uniqueness to just stick
with the default namespace, but gives others the option of overlap.

I know there are some concerns about the wisdom of allowing NVR overlap
at all. If you have cocerns one way or the other, please raise them here.


More information about the buildsys mailing list