SourceForge fetch group (was: Re: [86151] trunk/dports/audio/liblo/Portfile)

[Ryan Schmidt]

On Oct 21, 2011, at 21:22, Daniel J. Luke wrote:

> We actually should probably just let the sourceforge redirect do it's 'magic'

That's what I initially suggested:

http://lists.macosforge.org/pipermail/macports-dev/2011-May/014793.html

This was Joshua's reason not to do that:

http://lists.macosforge.org/pipermail/macports-dev/2011-May/014813.html

He said: "The original reason (r21768) for having more than just the redirector was in case it goes down. The main downside to removing the rest now is that the ping time for the redirector is not the same as that of the mirror it redirects to, but it will be compared to those of the MacPorts mirrors during sorting."

The original reason seems to no longer apply. Yes, we had multiple sites listed so that if the redirector was down, users would not get a fetch failure. That's no longer a concern since we now have our own network of mirror servers. Also, I think it would be very unlikely that the redirector would be down for long, since it's a rather important part of the SourceForge infrastructure.

The second reason is still a concern. As Joshua says, the ping time to the redirector is not the same as the ping time to the server it would send you to. Imagine we list only the SourceForge redirector, and imagine a user in a country that is not near to any of our mirror servers nor to where the SourceForge redirector is hosted, but there is a SourceForge mirror nearby. MacPorts might fetch from the nearest (yet still far away) MacPorts mirror, when the user would get a faster download by using the nearby SourceForge mirror.


> and fallback to pinging sites and selecting a mirror from the list only if there's a problem with the main site

This would require changes to MacPorts base. We don't currently have the ability to define groups of master_sites with different priorities -- except the hardcoded list of fallback servers which are tried last.


> (it's very likely that it can do a better job than we can of directing people to an appropriate server).

That's possible; it probably does some kind of geoip location. Which we could also do, as I've suggested before: we could route all our downloads through a redirector, just like they do.