Geoff Teale wrote: > I do agree that some dynamic look-up of mirrors would be a much better > solution than having users edit files in /etc. Considering that the default urls pointing back to redhat.com are actually redirects, it seems plausible to me that there is some intent to be able to provide some dynamic mirror rotation behind those default redirect urls...though i've seen no actually discussion confirming my deductive powers. And if the right people haven't already thought that far ahead, i hope they don't have me /dev/null'd in their procmail filters and have a light bulb moment. I certainly don't take credit for the idea...but it seems a pretty obvious use of the redirect urls. Though I have no idea if 'infrastructure' is in place for that, nor do I claim a full comprehensive of any ancillitory concerns like security or syncing issues and what the current view from the official mirror maintainers about being part of a round robin redirect. It could be more complicated than i think it is....but I'd love to here informed opinion on the matter..even if its just a chorus of rasberries. Of course a client side selection of mirrors would also be useful. But here you have decisions to be made about when the user gets presented a choice, is this first boot worthy?...and whether the mirror list you get to choose from is a static one or is pulled from a central location at selection time. I'd imagine the specifics about how a client would actually negotiate a mirror list would be best left to the specific mailinglist associated with the client tool in question. Though having an official mirrorlist xml file format or equivalent for tools to parse would be a trivial but noteworthy discussion. Having all the tools agree to use the same mirror file format would be nice. Then there is the 3rd option..which i think is going to be a much more lively debate. About having a point and click way for people to go to a website of mirrors (or even 3rd party repos) click a link..and configure their update tool. This opens up things to have community webpages of 'unofficial' lists of repositories like livna which cant be official spoken of in the distro because of US legal constraints. But I bet someone has a rational argument saying this sort of things presents a higher security risk. But I certainly don't know how to evaluate the risk of this in a selinux powered FC2 world(okay I admit i wouldn't know how to evaluate the security risk in an un-selinux FC1 world...but I hope selinux affects the security of this sort of action.) I don't expect all the tool writers to agree that this sort of thing is appropriate...but it seems to fit in with how up2date is suppose to be used, so it seems appropriate for consideration for whatever is going to be the up2date gui equivalent in fc2. -jef
Attachment:
signature.asc
Description: This is a digitally signed message part