DesktopManager @0.5.3 is still broken after rebuilding it

[ballapete (Peter "Pete" Dyballa)]

After selfupdate port recommended to "reclaim" some ports or such. This time it did not remove old source archives, it also uninstalled not requested ports, for example cmake or the DesktopManager which was running on my PowerBook G4 in order to have some tidy desktops. Now Desktop Manager does not correctly *install*:

--->  Found 5 broken files, matching files to ports
Error: Port DesktopManager is still broken after rebuilding it more than 3 times.
DEBUG: rev-upgrade failed: Port DesktopManager still broken after rebuilding 3 times
    while executing
"error "Port $portname still broken after rebuilding $rebuild_tries time${s}""
    (procedure "revupgrade_scanandrebuild" line 306)
    invoked from within
"revupgrade_scanandrebuild broken_port_counts $opts"
    ("uplevel" body line 3)
    invoked from within
"uplevel 1 $body"
Error: rev-upgrade failed: Port DesktopManager still broken after rebuilding 3 times
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

Desktop Manager built, so no main.log, but it installed incorrectly, as ls -AlR /Applications/MacPorts/Desktop\ Manager.app/ reveals:

/Applications/MacPorts/Desktop Manager.app//Contents/Frameworks/DesktopManager.framework:
total 24
lrwxrwxrwx   1 root  admin   31 21 Jul 15:42 DesktopManager -> Versions/Current/DesktopManager
lrwxrwxrwx   1 root  admin  216 21 Jul 15:42 DesktopManager.framework -> /opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_aqua_DesktopManager/DesktopManager/work/DesktopManager/build/UninstalledProducts/DesktopManager.framework
lrwxrwxrwx   1 root  admin   26 21 Jul 15:42 Resources -> Versions/Current/Resources
dr-xr-xr-x   4 root  admin  136 21 Jul 15:42 Versions

/Applications/MacPorts/Desktop Manager.app//Contents/Resources/DockExtension.bundle:
total 8
dr-xr-xr-x   4 root  admin  136 21 Jul 15:42 Contents
lrwxrwxrwx   1 root  admin  212 21 Jul 15:42 DockExtension.bundle -> /opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_aqua_DesktopManager/DesktopManager/work/DesktopManager/build/UninstalledProducts/DockExtension.bundle

So it must be only some issue in Makefile or such…

[ryandesign (Ryan Carsten Schmidt)]

The symlinks pointing to build directories are unsightly and shouldn't be there, but they're not causing any problems and that's not why MacPorts says the port is broken and tries to rebuild it.

The real problem is that the Desktop Manager program is linked to its internal framework incorrectly—it's looking for the framework in the wrong location, so the program crashes if we try to run it:

dyld: Library not loaded: /Applications/MacPorts/DesktopManager.framework/Versions/A/DesktopManager
  Referenced from: /Applications/MacPorts/Desktop Manager.app/Contents/MacOS/Desktop Manager
  Reason: image not found
Trace/BPT trap

I believe this problem was introduced 11 years ago in [335139f88298873aa1b1b65aa5c7386ce33c0866/macports-ports] when the port was converted from a manual build process to the xcode-1.0 portgroup. It was probably not realized at the time that this port's Xcode project file uses custom values of INSTALL_PATH to link the program and the internal framework together with a relative path so that the application can be installed anywhere, and that the xcode-1.0 portgroup would overwrite that custom INSTALL_PATH with an inappropriate value that would make the program link incorrectly. The port's revision was not increased at the time this change was made, presumably because it was erroneously believed that the change would not be visible to users, so if you had installed the port prior to August 14, 2007, you would not have been affected by this problem unless you reinstalled the port, as you now have.

[ryandesign (Ryan Carsten Schmidt)]

In 4abca81870598d46d90c32769ad72f447589179e/macports-ports (master):

DesktopManager: Don't override INSTALL_PATH

Overriding the INSTALL_PATH set by the Xcode project causes the app to
link to the framework at a nonexistent path, and thus the app can't find
the framework and can't launch and is considered broken by rev-upgrade.

Also, override the destroot phase, since the Xcode destroot phase just
rebuilds everything for no good reason, and causes symlinks to the build
directories to be placed inside every bundle and framework.

Closes: #56850

[ballapete (Peter "Pete" Dyballa)]

I built here again, installed correctly – and works!