| 1 |
Hi Michael, |
| 2 |
|
| 3 |
Thank you for pointing that out. |
| 4 |
|
| 5 |
My use case was about my personal overlay that is not mirrored by Gentoo |
| 6 |
infrastructure. |
| 7 |
|
| 8 |
My question started with the network sandbox issue when we need to load |
| 9 |
external code dependencies. For example, a go project will download all |
| 10 |
dependencies from git repositories that will happen after src_unpack. In |
| 11 |
this case I need to add an additional tar.gz with that code along with |
| 12 |
the software release tar.gz. |
| 13 |
That additional tar.gz needs to be stored somewhere and as I understand |
| 14 |
local mirror could be the right place. |
| 15 |
|
| 16 |
Thanks, |
| 17 |
|
| 18 |
Samuel |
| 19 |
|
| 20 |
On 3/31/20 11:47 PM, Michael Orlitzky wrote: |
| 21 |
> On 3/31/20 6:21 PM, Samuel Bernardo wrote: |
| 22 |
>> But after your explanation, I understand now that mirror types provides |
| 23 |
>> alias to use in ebuild SRC_URI, specially useful for the update task |
| 24 |
>> (awesome). |
| 25 |
>> |
| 26 |
> Beware: thirdpartymirrors doesn't really do anything useful for normal |
| 27 |
> ebuilds in ::gentoo. The gentoo infrastructure will automatically mirror |
| 28 |
> anything in SRC_URI unless you set RESTRICT=mirror -- and that's where |
| 29 |
> most people will download them from -- so (for example) adding a bunch |
| 30 |
> of extra thirdpartymirrors entries to ensure that the distfiles are |
| 31 |
> accessible is counter-productive: everyone will get the stuff from the |
| 32 |
> gentoo mirrors anyway, and you wind up with a bunch of dead entries in |
| 33 |
> the thirdpartymirrors file (at least half of the entries in there right |
| 34 |
> now are dead, and no one is ever going to clean them up because no one |
| 35 |
> uses them). |
| 36 |
> |
Archives