1 |
I've been giving a lot of thought about how to deal with things like the |
2 |
mirror rush we had when kde-3.1 was released, and we got downgraded to |
3 |
second-class citizens on ibiblio :), or releases of new ISOs. I think |
4 |
I've come up with a workable solution, easy to implement in portage, but |
5 |
it would require an infrastructure addition. We could add bittorrent |
6 |
(http://bitconjurer.org/BitTorrent/) support for larger packages. I say |
7 |
larger packages, because bittorrent doesn't work well for small files. |
8 |
Here is what I envision it entailing. |
9 |
|
10 |
A bittorrent server (this is the infrastructure part), that maintains |
11 |
torrents of the larger packages (I define larger as 20MB+), such as |
12 |
XFree. |
13 |
|
14 |
Additional FEATURE: |
15 |
bittorrent |
16 |
|
17 |
Additional var in ebuilds: |
18 |
TORRENT_URI=http://torrent.gentoo.org/${A}.torrent |
19 |
|
20 |
(though, seeing as how we already have the file name, and therefore, the |
21 |
torrent file name, it could just as easily be HAS_TORRENT=1, or maybe we |
22 |
just maintain a database of which packages have torrents available that |
23 |
portage checks) |
24 |
|
25 |
What happens now is, if the user has the bittorrent FEATURE enabled, AND |
26 |
has bittorrent installed (much like what is required to use the ccache |
27 |
feature), and the package has a torrent available, we can then use |
28 |
btdownloadheadless.py or btdownloadcurses.py to download the file (ie, |
29 |
btdownloadheadl.py --url http://torrent.gentoo.org/${A}.torrent --saveas |
30 |
/usr/portage/distfiles/${A}). This takes load off of the download |
31 |
mirrors, and helps everybody achieve maximum bandwidth while |
32 |
downloading. |
33 |
|
34 |
Any thoughts? |
35 |
|
36 |
Cheers, |
37 |
|
38 |
Caleb Shay |
39 |
caleb@××××××××.com |
40 |
|
41 |
|
42 |
|
43 |
|
44 |
-- |
45 |
gentoo-dev@g.o mailing list |