port upgrade outdated order

[Chris Jones]

On 04/03/15 17:24, René J.V. Bertin wrote:
> On Wednesday March 04 2015 16:52:50 Chris Jones wrote:
>
>> If upstream cannot/wont fix, then if we want to keep the port in
>> MacPorts, it should be worked around. trace mode (or anything that does
>> the same thing, hides the installed version) strikes me as perfect here.
>
> Agreed - and that's exactly an example of a case where some form of requiring trace mode in the portfile would be useful.

I think we are just niggling over the details here. I am not sure I see 
the need for ports to be able to opt in or out of tracemode (out should 
be just not possible, but I could be persuaded on opting in). For me, 
trace mode is much more than a 'debugging' tool, but a means of 
sanitising the build environment to limit the build from only having 
access to what we want.

> As to fixing ... the experience many of use have had with /usr/local can probably serve as an example/metaphor for why it's not always feasible to avoid including the wrong version of a header... (and I guess it should be easier to exclude or demote a directory from outside the prefix than to exclude/demote ${prefix}/include ...)

I don't see whay you say its not feasible. tracemode would absolutely 
prevent access to /usr/local during building, which is a very good 
thing. It would also only allow access to the files the ports the port 
in question being built has declared a dependency on. As MP knows 
exactly which files a given port has installed, this can be done on a 
file by file level. This should pretty well cover any use case of a port 
building against things it shouldn't, regardless of if those files are 
under /usr/local (just a blanket ban) or more fine grained control under 
${prefix}.

Chris

>
> I wasn't completely PC about the exchange I had on the Qt ML: apparently attempts had been made to correct the particular issue I reported, which turned out to be too tricky.
>
> R.
>