Opened 16 years ago

Closed 15 years ago

#18302 closed enhancement (fixed)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.8.0
Component: base Version: 1.7.0
Keywords: Cc:
Port:

Description

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

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.

Change History (4)

comment:1 Changed 16 years ago by 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).

comment:2 in reply to:  1 Changed 16 years ago by 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.

comment:3 Changed 16 years ago by 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.

comment:4 Changed 15 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.