Sorry for my English.

= Idea =

Port isolation :). When MacPorts build port it can deny to see files that port should not see.

= Current status =

It almost work :) 

SVN commits: r26682 r28091 r28147 r29367 r29369 r29641 [[BR]]
Sources: [source:trunk/base/src/darwintracelib1.0/darwintrace.c darwintrace.c] [source:trunk/base/src/port1.0/porttrace.tcl porttrace.tcl] [source:trunk/base/src/port1.0/portutil.tcl portutil.tcl] [source:trunk/base/src/pextlib1.0/tracelib.c tracelib.c] [source:trunk/base/src/pextlib1.0/tracelib.h tracelib.h]

== How it works  ==

=== tracelib ===
port command opens unix socket in /tmp/macports/{pid of port command} and injects tracelib into process' address space. Tracelib hooks close, execve, lstat, mkdir, open, readlink, rename, rmdir, stat, unlink. 

When some activity is occurred, it looks at filemap. There are 4 cases:
 1. path marked as 0           — grant access
 2. path marked as 1           — do redirect
 3. path marked as 2           — ask port command for advise
 4. path not listed in filemap — deny and report incident to port command

When fourth case is occurred you'll see something like “{{{Warning: A creation/deletion/modification was attempted outside sandbox: /etc/group}}}”. It a little bit incorrect, because it can happen on read/stat actions too. But it is old Paul's warning, and I don't know why I didn't change it :)

When third case is occurred tracelib asks port command about permit to interact with file. If it says no you'll see “{{{trace: access denied to /opt/local/bin/perl (perl5.8)}}}”. If it says yes we allow access to file. Unlike fourth case dirs are ignored.

=== Filemap ===

Filemap is piece of memory in form:
  {{{path\0action[redirect_path]\0path\0\action...path\0action[redirect_path]\0\0}}}

path is path prefix (for example, `/` matches all paths, `/opt` matches `/optblah/blah` and `/opt/blah etc`)[[BR]]
action is actions listed before[[BR]]
redirect_path is path for !SDK redirection, present only with 1 action.[[BR]]
\0 — is byte with code zero

Filemap's building performed [source:trunk/base/src/pextlib1.0/tracelib.c@29369#L170 here]. And it can be influenced by tcl code [source:trunk/base/src/port1.0/porttrace.tcl@29641#L76 here].

=== SDK redirection === 

There are SDKs in `/Developer/SDKs/`. Tracelib can map `/` to SDK dir.

Example:
We building port with SDK `MacOSX10.2.8.sdk`. gcc wants to use `/usr/include/stdio.h` and calls open(`/usr/include/stdio.h`), but tracelib returns open(`/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/stdio.h`). 

But there are some problems. 
 1. I don't have any version of Mac OS X but 10.4, and can test, but I think there will be issues with ABI, and version of gcc.
 2. Some files missed in SDK directory (for example CPAN).

== User's part == 

User can use SDK redirection by specify `--with-trace-sdk=SDK`

Port trace can be enabled by specifying option -t for port command. For example:
  {{{sudo port -t install ghc}}}

== Problems ==

Some ports can reject to build in port trace mode because of sandbox. For example before r29641 you could not build gtk (it use files dir in $portdir, which wasn't allowed for read).

There are common programs (like gawk or perl) which dirt output. 

SDK redirection is untested in real world. 

== How it can be used ==

Maintainers can test dependencies with it. 

MacPorts can provide binary packages (SDK redirection is for it) :)