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.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
