Hi Michał, On 3/27/20 5:59 AM, Michał Górny wrote: > Stop here. If you think that you need to 'break network sandbox', you > already have the wrong attitude and shouldn't continue. Network sandbox > is not your enemy. Using network is. > > Network sandbox protects users from paying extra because you've written > a bad ebuild that unexpectedly downloads lot of data on their mobile > connection. Network sandbox makes sure that we don't end up delivering > stuff that doesn't work to people who are on isolated networks or simply > have non-permanent connections. Network sandbox makes sure that these > ebuilds will work three months from now when upstream randomly decides > to remove old files or shuffle servers, or just get hits by a temporary > issue. > > There's no 'breaking the network sandbox'. You must fix the ebuild not > to require Internet.
That is an awesome concept for producing ebuilds, since I could be using dist-cc and compiling multiple profiles using dedicated computing cluster leveraging available resources within a sandbox with very restricted access. This is a very nice pattern on resource management. This is another reason why I like Gentoo very much, with the SQA assurance of the high quality rules, and persuade me to invest my time using this wonderful distro. I understand that network sandbox only restricts the build environment, but wouldn't the urls in SRC_URI be a problem when referencing sites that are not reliable? Shouldn't be relevant to define those sites that give better assurance for syncing the required binaries? Same question for unpack context when using directly the source repository with vcs functions. Best, Samuel
signature.asc
Description: OpenPGP digital signature
