How identify and remove leftover files on buildbots?

[Marko Käning]

Hi Joshua,

On 02 Nov 2014, at 04:11 , Joshua Root <jmr at macports.org> wrote:
> Grep the ports tree for 'registry_file_registered' to find examples. One
> is gdbm. If this isn't on the PortfileRecipes page, it probably should
> be. (Although new instances of this problem should be rare thanks to
> sandboxing.)

oh, yes, this little feature should be on wiki and Guide…

Thanks to peeks into gdbm and canto I came up with this:

---
pre-activate {
    foreach file {glob ${prefix}/Library/Frameworks/R.framework/Resources/library/} {
        set filepath ${prefix}/${file}
        if {[file exists ${filepath}] && [registry_file_registered ${filepath}] == "0"} {
            ui_warn “Deleting residual file ${filepath}”
            file delete -force $filepath
        }
    }
}
---

but it seems to NOT be the right way to go, as it results in

---
$ # CREATE A TEST ENVIRONMENT:
$ sudo mkdir -p /opt/local/Library/Frameworks/R.framework/Resources/library
$ sudo touch /opt/local/Library/Frameworks/R.framework/Resources/library/testfile
$
$ # ACTIVATE THE PORT:
$ sudo port activate 
--->  Computing dependencies for R
--->  Activating R @3.1.1_0+accelerate+cairo+gfortran48+recommended
Error: org.macports.activate for port R returned: Image error: /opt/local/Library/Frameworks/R.framework/Resources already exists and does not belong to a registered port.  Unable to activate port R. Use 'port -f activate R' to force the activation.
---

meaning that R.framework/Resources is of course registered in the MacPorts tree, which is why the
pre-activate phase has no chance to act here.

So, it seems that port intervenes *before* I even get the chance to do what I intend. Do I need to
use another port phase to achieve this?

How do I deal with this now, since one cannot force activation on the buildbots, I suppose.

Greets,
Marko