Improving trace mode

[Rainer Müller]

Jordan K. Hubbard wrote:
>  From what I recall from the conversations between Paul Guyot, Landon  
> Fuller, and others behind trace mode, this is sort of the point.  A  
> port is supposed to declare its dependencies, not write to areas  
> outside of MacPorts' control, and otherwise behave itself.  If it's  
> not behaving itself then one might argue that it *should* fail so that  
> a bug report will be filed appropriately.  Unless I misunderstand your  
> proposal completely, it sounds like you want to simply neuter trace  
> mode so it's no longer, in effect, fulfilling its expected purpose.

I understand that trace mode was meant to catch any access outside of
the scope of the dependencies, but at the moment it just does not work
in this way.

There are currently some binaries on which most ports do not declare
dependencies on, for example grep and awk.

For grep it is sufficient to add bin:grep:grep to depends_build. But for
awk, most configure scripts are satisfied by either gawk or awk, with
preference of gawk. There is currently no way to specify such a
dependency with alternatives. Specifying bin:awk:gawk is a workaround,
but actually it is wrong - gawk does not provide a binary named 'awk'.
Without trace mode, it would be using ${prefix}/bin/awk, but with trace
mode it falls back to /usr/bin/awk due to 'Permission denied' on the
first one. That is what I mean with "behave differently".

I have seen some configure scripts trying to access gmkdir, gnm, gstrip,
etc. (provided by coreutils/binutils), but they also just use the
non-gnu binaries in /usr/bin if g* is not available. Here we have the
same problem as for gawk.

There are a lot of these standard tools configure scripts may check for.
As a port author I just give up at that point, because adding them all
to every port is a lot of work, although only needed if the GNU tools
are installed through MacPorts (some ports even explicitely require GNU
tools).

When using trace mode, I always get messages:
  Warning: An activity was attempted outside sandbox:
/var/root/.CFUserTextEncoding
What is this?

Further problems are ccache and distcc. No port declares a dependency on
them as they are added by base. This is issue #12218 [1]. Probably this
could be fixed by adding a dependency if they are used, but no actual
patch is there yet.

And last, I would rather have trace mode report all issues at the end
than having to run it over and over again. If access to some file is
denied, the build usually fails and I have to edit the Portfile for that
dependency, run the command again, until it fails for the next file
again, edit the Portfile, ...

In my opinion it would be more useful if it would just print out a list
of files the build accessed outside the sandbox without interrupting the
build.

Rainer

[1] http://trac.macports.org/ticket/12218