| 1 |
On 01/21/2015 05:05 AM, Michał Górny wrote: |
| 2 |
> Hello, developers. |
| 3 |
> |
| 4 |
> As you may recall, the main blocker for wide-establishment of |
| 5 |
> FEATURES=network-sandbox prohibiting network access within the build |
| 6 |
> environment is distcc. Since all connectivity is disabled, distcc can |
| 7 |
> no longer reach other distcc servers and build efficiently. I therefore |
| 8 |
> find it important to figure out a solution. |
| 9 |
> |
| 10 |
> ... |
| 11 |
> |
| 12 |
> Any other ideas? |
| 13 |
> |
| 14 |
|
| 15 |
We probably won't avoid the fact that some features are incompatible |
| 16 |
forever. Why not just let the combination be broken? Distcc isn't |
| 17 |
enabled by default, so having network-sandbox enabled won't immediately |
| 18 |
cause problems. |
| 19 |
|
| 20 |
We can document that, when enabling distcc, you have to set |
| 21 |
FEATURES="-network-sandbox". No one will read it, so that leaves the |
| 22 |
question of what to do when both are enabled. |
| 23 |
|
| 24 |
1. Break normally. We can point people to the man page. |
| 25 |
|
| 26 |
2. Disable network-sandbox and emit a warning. |
| 27 |
|
| 28 |
3. Disable distcc and emit a warning. |
| 29 |
|
| 30 |
The third is my favorite, since it's the non-default feature and the |
| 31 |
warning will be more helpful: "to enable distcc, you must add |
| 32 |
"-network-sandbox" to your FEATURES in make.conf..." |
| 33 |
|
| 34 |
If the point of network-sandbox is to catch mistakes, having it enabled |
| 35 |
for 95% of users is just as good as 100%. |
Archives