On Thursday 17 July 2008, Mike McLean wrote:
Mike Bonnet wrote:
This is mostly in line with what I've been thinking. I do have a few
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
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
i would think there should be a 1-1 mapping of tag external repo
Doing something like this would most likely require Koji to
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.