Supporting EPEL Builds in Koji

[Dennis Gilmore]

On Thursday 17 July 2008, Mike McLean wrote:
> 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.
In addition to external koji servers, id like to support spacewalk servers. 
and have the ability to push builds back into channels on spacewalk servers. 
ideally the spacewalk server knows how to pull from koji server rather than 
duplicating data by importing directly.  this way an organisation could build 
upon fedora/RHEL/CentOS for their own needs.  but can also have an easier time 
doing rel-eng on them.

> 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.
i would think there should be a 1-1 mapping of tag external repo  using normal 
inheritence.  
> 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.
I can see a case where this wont work.  i have a local tag built on top of F-8  
i want it lower than  the remote F-9 because some of what i need is now in 
fedora,  but i need other bits from my tag to be inherited so that i can boot 
strap things to the F-9 level.   maybe we would produce 2 local repos and use 
yum priorites.  to fit them together. maybe this case is rare enough not to 
bother with.  but it could be an idea to keep in mind.

-- 
Dennis Gilmore

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-buildsys-list/attachments/20080717/1ed6001f/attachment.sig>