MacPorts doesn't recreate manpage symlink after compressing manpage if symlink is absolute

[ryandesign (Ryan Carsten Schmidt)]

MacPorts base has this nifty feature whereby it automatically gzips manpages after the destroot phase. It then looks for any symlinks in the destroot that point to the now-compressed manpages, and deletes and re-creates them pointing to the gzipped versions (since the manpage filenames have changed through the addition of ".gz"). This works great...

...until a port installs a symlink pointing to an absolute path instead of a relative one. Boom, the symlink doesn't get recreated anymore and we have problems with

• coreutils (#15864)
• findutils (#18227)
• pure, pure-devel (#18294)

and probably more.

The real kicker is that MacPorts base sometimes correctly re-links an absolute symlink: when a previous version of the port is already installed! since then the target of the symlink (with the addition of ".gz") exists.

MacPorts should see if the manpage symlink path is absolute, and if so, prepend the destroot path, or something like that.

[lperry (Perry Lee)]

From my brief testing, prefixing the destroot path to the absolute path is not what you want; you end up with symlinks referencing paths in destroot.

Instead, I tried converting the absolute symlinks to relative symlinks, which as far as I can tell (at least from the listed examples and the following lines in portdestroot.tcl) is simply the file name:

231                         set mandir [file dirname $manlink]
232                         set mandirpath [file join $manpath $mandir]
233                         set pwd [pwd]
234                         if {[catch {_cd $mandirpath} err]} {
235                             puts $err
236                             return
237                         }

I've gone ahead and committed this possible fix in r47111 (it fixes #18227 at least).

[ryandesign (Ryan Carsten Schmidt)]

Replying to perry@…:

From my brief testing, prefixing the destroot path to the absolute path is not what you want; you end up with symlinks referencing paths in destroot.

What I meant was, when checking to see if the target of the symlink exists, prepend the destroot if the target is an absolute path. When creating the new replacement symlink to the compressed manpage, of course you would not prepend the destroot.

[lperry (Perry Lee)]

Ah, my bad; at the time, I wasn't thinking straight and just prefixed manlinksrc with destroot (when it was an absolute path) and forgot to remove it when recreating the symlink.

[jmroot (Joshua Root)]

I implemented what Ryan suggested in r53272, so we're not messing with the path type.