dangling symlink created in ${destroot}${prefix}/lib, AFTER post-destroot?

[René J.V. Bertin]

Hi,

I'm testing a Qt5 subport for port:attica, which installs a dangling and unneeded libattica.0.dylib symlink in the destroot. I thought it'd be easy to remove it using `file delete ${destroot}${prefix}/lib/libattica.0.dylib`, but that operation appears to do nothing. `[file exists ${destroot}${prefix}/lib/libattica.0.dylib]` also returns false, but when I print ${destroot}${prefix}/lib/libattica.0.dylib using ui_msg and then check the result (after `port destroot` terminates), the file does exist.

In fact, it would seem that the dangling symlink is created AFTER post-destroot completes; possibly related to

:debug:destroot Executing portdestroot::destroot_finish
:debug:destroot Fixing glibtool .la files in destroot for attica-qt5

I see in the log?

NB: my installed and active port:attica does have a valid libattica.0.dylib symlink . The Qt4 and Qt5 versions of attica create dylibs with a different numbering scheme, so those libraries should be able to co-exist and not run into a conflict because both ports install the same symlink.

I never saw anything like this with base 2.3.3 ...

R.