Supporting EPEL Builds in Koji

[Mike McLean]

Mike Bonnet wrote:
> http://fedoraproject.org/wiki/Koji/EPELSupport

This is mostly in line with what I've been thinking. I do have a few
comments/concerns thought...

If the remote_repo_url data is going to be inherited (and I tend to
think it should be), then I think it should be in a separate table. I'd
like to reserve tag_config for data that is local to individual tags.
This will also make it easier to represent multiple remote repos.

I'm a little concerned about using the rpminfo table. Yes, I know it
seems wasteful to introduce another table to track very similar data,
but these remote rpms really are differently tracked and handled than 
the local ones.

Also, I'm not sure how I feel about having rpminfo entries will null 
build_id. Sure, technically the field lacks the 'not null' constraint, 
but that is more of an oversight.

Note, I'm not outright rejecting the idea of using rpminfo this way, but 
I am concerned.


As for the origin field. I think we should track where these external 
rpms come from, but I'm not sure about including in the uniqueness 
constraint. I'm not sure that the value of that field is sufficiently 
well defined (or canonicalizable) for such use. I'd rather see the 
sigmd5 value (or some abstracting sighash field) used as a unique index.


Following are additional ideas relating to this feature. They are 
perhaps a bit ambitious for the short term, but I'd at least like to 
keep them in mind with the initial design so we don't paint ourselves 
into a corner.

First, I'd like to be able to support external koji servers (or rather a 
target or tag from an external koji server) in addition to external 
repos. Some of the ideas are the same, however an external koji server 
provides more information and more structure.

Second, I'm fond of having a tag /represent/ some external repo/whatever 
and having the normal inheritance mechanism take care of priority. The 
trick here is that Koji tag content is by build, but it will be tricky 
to correctly determine build structure for external rpms -- indeed, 
external repos might include subpackages from different versions of the 
same build (the an external koji server would not, at least for its 
local content). So this will probably be difficult, but if we could 
manage something like this, I'd feel a lot better about using the 
rpminfo table.

Doing something like this would most likely require Koji to comprehend 
the external repos instead of just passing them off to a repomerge tool.

Third, we may not want to use a repomerge tool. The yum-priorities 
plugin might serve just as well, and allow us to specify some different 
yum repo options per external repo. This may conflict with idea#2 though.