| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Hiya, |
| 5 |
|
| 6 |
First off, thanks everybody for the suggestions. It seems like people |
| 7 |
aren't keen to mirror the large tables on our mirrors, but no one's |
| 8 |
mentioned a reason for not doing so. Is there an infra reason behind |
| 9 |
that or did everyone just take my caution and run with it? |
| 10 |
|
| 11 |
On 16/10/13 02:40, Chí-Thanh Christopher Nguyễn wrote: |
| 12 |
> I suggest that you add a "large" USE flag, and if it is enabled, |
| 13 |
> download and install the whole thing. If disabled, just print the |
| 14 |
> URLs in a log message, so the user can download themselves if they |
| 15 |
> wish. |
| 16 |
|
| 17 |
So downloading them manually is a pain (the larger tables aren't in a |
| 18 |
single zip, they're split amongst 12 files for each table), and the |
| 19 |
ebuild to do the downloading is already built. I'll include a |
| 20 |
postinst note indicating that the tables are getting stored twice, and |
| 21 |
I should even be able to give them an indication of how much space |
| 22 |
they're wasting. I'll also provide a URL they can visit if they want |
| 23 |
to download manually instead. |
| 24 |
|
| 25 |
The question then becomes, do I split the ebuild into two (giving us |
| 26 |
three ebuilds for what is otherwise a tiny package) just so some SRCs |
| 27 |
are mirror-restricted and others aren't? All of that hinges on |
| 28 |
whether our servers can handle the extra size... |
| 29 |
|
| 30 |
Mike 5:) |
| 31 |
-----BEGIN PGP SIGNATURE----- |
| 32 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 33 |
|
| 34 |
iEYEARECAAYFAlJeWR4ACgkQu7rWomwgFXq8bQCfRde/Tg7sAirqT05d5spckC+s |
| 35 |
fUIAoIH1SlXvLmM3CqM0x1vQN0oPdiKi |
| 36 |
=qqsa |
| 37 |
-----END PGP SIGNATURE----- |
Archives