MacPorts 2.8.1 does not create a symlink to source when worksrcpath is specified

[essandess (Steve Smith)]

MacPorts 2.8.1 does not create symlink to source when worksrcpath is specified.

This is breaking behavior from version 2.8.0. See e.g., #66690.

The problem with the latest MacPorts version is that the worksrcpath specified by the Portfile is created as an actual directory, not a symlink to the untarred source contents created by the extract phase. This will be a problem with any port that specifies worksrcpath—I cannot recall why I did this for cabal but I believe that there was a good reason. See below.

How to observe the issue. The directory cabal-install-3.8.1.0 should be a symlink to cabal-Cabal-v3.8.1.0.

sudo port -sd patch cabal
# process hangs
^C

ls -l /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_cabal/cabal/work/
total 0
drwxr-xr-x  53 macports  wheel  1696 Feb  3 05:44 cabal-Cabal-v3.8.1.0/
drwxr-xr-x   2 macports  wheel    64 Feb  3 05:44 cabal-install-3.8.1.0/

​https://github.com/macports/macports-ports/blob/b9c71b3bf2561a10fd6e0b64ca31859944a6e6f5/lang/cabal/Portfile#L99

    worksrcdir      ${name}-install-${version}

[kencu (Ken)]

this was all done on purpose, to fix other bugs caused by creating the symlink.

see the recent base commits where it is explained fully.

Many ports will need fixing for this new reality, however….

[essandess (Steve Smith)]

So how does one get the symlink back??

There must be some simple Portfile flag, right?

[kencu (Ken)]

extract.rename yes

but if you set worksrcdir as well, it might not work… I have to read the code again to see exactly how Josh wrote it to work…

[ryandesign (Ryan Carsten Schmidt)]

Closing because the change is intentional, as documented in the 2.8.1 release notes.

Either set worksrcdir correctly or use extract.rename yes.