Comment 34 for bug 247351

(In reply to comment #16)
> (In reply to comment #15)
> > The new mirrorlist channel definition is currently the 'approved' method of storing dynamic mirrors
> Can you point me to the approval? If it is approved, why isn't it in the
> sources?

Good question! Don't know is the answer. Actually, although not well documented Smart is plugin based. The idea being that for certain additional functionality the end user can just add a plugin for that functionality. this applies to backends, channels, mirrors etc. There are some guidelines which are only discovered by asking on irc atm :) So adding a mirrorlist channel is implicitally approved as it is just another plugin. This is the way method one works. Method two on the other hand actually changes the way Smart works with rpm-md (rpm metadata) channels (from a higher level design point). Method 2 is a better way from the end user perspective as you can see and edit the mirrors. I use method 2 preferentially over method 1.

> > As no agreement has been reached in approving the second method yet you should
> > be ok using the mirrorlist channel (first method).
> Actually I just found out that you are the author of the first method, and
> upstream seems to favour the other one (there were some comments that seem to
> have been resolved and are waiting for a new merge review by upstream).
> I'm sorry, Fedora should stay close to upstream and if upstream looks like
> going one direction Fedora shouldn't be going the other way. Please note that
> I'm not commenting on whether method A or B is better, and your work on
> improving smart for Fedora is acknowledged!

Thanks, I'm not pushing either method though, you know from a self agrandisment perspective :) I am suggesting that Fedora use method one as a plugin suitable for Fedora (mirrorlist channel), right now, as it provides sorely needed functionality and does not alter the way Smart inherently works so it won't break future compatibility (so is upstream approved) . Should method two become incorporated in the base code then move to that in future as it is a nicer way of doing the same thing (mirror information is kept with repo information, mirrors are user editable, etc). Using either method in fedora will then increase it's likelyhood of being included in future Smart releases.

To summarise (the above is a bit abstract), Using a mirrorlist channel is implicitly approved (by upstream) as it is a plugin (method 1) and adding mirror functionality to rpm-md channels (method 2) needs explicit approval as it modifies the base code and might break backwards compatibility.

If you want I can provide the bits neccessary for both if you want.