| 1 |
Alexandre Rostovtsev posted on Mon, 31 Mar 2014 14:54:09 -0400 as |
| 2 |
excerpted: |
| 3 |
|
| 4 |
> The best solution is to figure out why the directory is being created |
| 5 |
> there and whether it is customizable. Maybe the code actually is |
| 6 |
> creating $HOME/InstallShield? Then export HOME=${T} in your ebuild. |
| 7 |
|
| 8 |
Well, "best" would be not to run software where the author doesn't |
| 9 |
respect your rights to study, patch and share the software, with or |
| 10 |
without those modifications, in the first place. |
| 11 |
|
| 12 |
But understanding not everybody is prepared to go that route and it's |
| 13 |
their machines and life, not mine... |
| 14 |
|
| 15 |
On the ebuild execution side, as a last resort you can turn off |
| 16 |
FEATURES=sandbox and perhaps FEATURES=userpriv as well, allowing it free |
| 17 |
access to do whatever it's going to do. |
| 18 |
|
| 19 |
Alternatively and for both the ebuild creation and execution sides, take |
| 20 |
a look at /etc/sandbox.conf and the files in /etc/sandbox.d/, and grep |
| 21 |
SANDBOX_ in $PORTDIR/*/*/*.ebuild and $PORTDIR/eclass/*.eclass. |
| 22 |
|
| 23 |
(Tho it's not always proprietaryware; take a look at emacs... based on |
| 24 |
some of the other packages that disable sandbox, I'd guess it's the lisp.) |
| 25 |
|
| 26 |
Anyway, SANDBOX_PREDICT or SANDBOX_WRITE will probably do it in your case |
| 27 |
(violations not flat-out-segfaults as emacs apparently triggers), but |
| 28 |
SANDBOX_ON=0 is there if you REALLY need it. |
| 29 |
|
| 30 |
Tho obviously if you were doing that ebuild for the main tree, any |
| 31 |
messing with sandbox isn't going to get it there any faster. But if |
| 32 |
you're doing it for your own (including possibly company internal) use |
| 33 |
only... |
| 34 |
|
| 35 |
-- |
| 36 |
Duncan - List replies preferred. No HTML msgs. |
| 37 |
"Every nonfree program has a lord, a master -- |
| 38 |
and if you use the program, he is your master." Richard Stallman |
Archives