add BitTorrent as alternative for downloading ports
I discovered while trying to install Erlang's otp_src_R12B-4 that the standard HTTP download was taking forever, but there was a torrent file right next to it, and the torrent download went orders of magnitude faster. It would have been nice a) to have gotten feedback on the progress of the download and b) to be able to use (or fail over to) the BittTorrent download mechanism automatically. I took some notes on the macports.tcl script to sketch out how a BitTorrent client might be used instead of curl but have not tried out any of my code yet.
Change History (3)
| Resolution: |
→ wontfix
|
| Status: |
new →
closed
|
| Milestone: |
MacPorts Future
|
I would be surprised if there were many ports offering bittorrent as a download option, and there probably aren't any that require it. So I can't see a great need to add this to MacPorts.
Also, the way a torrent works is that it downloads from many peers, and you're supposed to be a good netizen and "seed" (upload to others) the torrent after you're done downloading it, to "pay back" the bandwidth you used to download it. But MacPorts can't accommodate that in its current implementation, since there is no persistent MacPorts process that sticks around. MacPorts would either have to grow a persistent process, which sounds like a major change, or else MacPorts would be a bad netizen when downloading torrents, which I don't think we want to be. Or MacPorts could continue to seed the torrent while it works on installing the software, but that would require other major changes to allow the seeding and the installing to happen concurrently.
We do already have a fix in MacPorts trunk for slow distfile download servers: we now have our own distfiles mirror hosted by Apple which is usually faster, and MacPorts trunk tries download servers in order of performance, rather than ain the order listed in the Portfile which is what 1.6.0 does.
You can already use the distfiles mirror with MacPorts 1.6.0 by following these instructions (and it will be used automatically as of MacPorts 1.7.0).