Created attachment 201474 [details] Makefile The port with the attached Makefile creates broken links for multiply defined GH_TUPLE elements. How to reproduce: 1. Save the attached Makefile as /usr/ports/devel/om/Makefile 2. cd /usr/ports/devel/om 3. Run: make makesum extract 4. Observe how all 'common' links except for one are broken: > $ ls -l ./work/OpenModelica-1.14.0-dev/OMEdit/common > lrwxr-xr-x 1 yuri users 41 Jan 28 00:28 ./work/OpenModelica-1.14.0-dev/OMEdit/common -> OpenModelica-1.14.0-dev/OMCompiler/common > $ ls -l ./work/OpenModelica-1.14.0-dev/OMEdit/common/ > ls: ./work/OpenModelica-1.14.0-dev/OMEdit/common/: No such file or directory > $ ls -l OpenModelica-1.14.0-dev/OMCompiler/common/ > ls: OpenModelica-1.14.0-dev/OMCompiler/common/: No such file or directory Only the first instance of 'common' is usable: ./work/OpenModelica-1.14.0-dev/OMCompiler/common All subsequent links that are supposed to link to it are broken.
Created attachment 206184 [details] patch The attached patch solves the problem. It should create links with the full path to the original directory.
Created attachment 206185 [details] testcase.shar Attaching the sample port that is fixed by this patch.
Damn, it took me a whole hour trying to see what you were doing and why it was wrong and broken. You cannot have the *exact same* account/project/commit more than once when using USE_GITHUB and/or USE_GITLAB. it breaks, like you demonstrated here. Remove the two extra OpenModelica-common:c9c9085 tuples and handle the symlinks yourself in post-extract (or maybe post-patch as post-extract may not be late enough). Your patch that "fixes" the problem is wrong, and only hides the bug in your port.
I admit, your ports were allowed to be broken because of how I implemented the GH_SUBDIR thing. review D21686 fixes the implementation and now your ports fail early.
(In reply to Mathieu Arnold from comment #4) They aren't broken. It's about net/zeek, not OpenModelica. net/zeek has a deep bundling structure and some projects are bundled multiple times at multiple different locations. There is nothing wrong with this, and this should be allowed. The attached patch fixes the invalid links that framework creates. It makes links valid, and the build of net/zeek succeeds.
Like I said, a account:project:hash tuple can only happen once in G[HL]_TUPLES, it is like adding the same file to DISTFILES more than once, it only bloats the distinfo file. If a port needs to have the same distfile accessible at multiple places, you can either extract it manually, or create symlinks yourself in post-extract.
To expand a bit, the framework is not there to automatically handle every whim of every port, it allows you to do most things automatically, and when you run into something that is does not do, it allows you to do so in the port's Makefile.
Created attachment 207614 [details] Makefile The corrected Makefile.
(In reply to Mathieu Arnold from comment #6) This situation with duplicates often happens with Go ports [1], [2] due to the way Go dependencies work. E.g. fsnotify:fsnotify:v1.4.7:fsnotify_fsnotify/vendor/github.com/fsnotify/fsnotify \ fsnotify:fsnotify:v1.4.7:fsnotify_fsnotify_1/vendor/gopkg.in/fsnotify.v1 \ fsnotify:fsnotify:v1.4.7:fsnotify_fsnotify_2/vendor/gopkg.in/fsnotify/fsnotify.v1 \ are 3 different packages as far as Go is concerned, but we get duplicates because we have to map them to Github mirrors. Looking at bsd.sites.mk code [3], it's not entirely clear why it does ${MV} first and then ${LN}: post-extract-gh-${_group}: @${RMDIR} ${WRKSRC}/${GH_SUBDIR_${_group}} 2>/dev/null || : @${MKDIR} ${WRKSRC}/${GH_SUBDIR_${_group}:H} 2>/dev/null || : @${MV} ${WRKSRC_${_group}} ${WRKSRC}/${GH_SUBDIR_${_group}} @${LN} -s ${WRKSRC:T}/${GH_SUBDIR_${_group}} ${WRKSRC_${_group}} After the move, there's nothing to link to anymore and two remaining fsnotify tuples from the example above get broken GH_SUBDIR symlink. Would changing ${MV}/${LN} to just symlinking tuple's WRKSRC to GH_SUBDIR break anything? E.g. post-extract-gh-${_group}: @${RMDIR} ${WRKSRC}/${GH_SUBDIR_${_group}} 2>/dev/null || : @${MKDIR} ${WRKSRC}/${GH_SUBDIR_${_group}:H} 2>/dev/null || : @${LN} -s ${WRKSRC_${_group}} ${WRKSRC}/${GH_SUBDIR_${_group}} It does seem to work in my (limited) testing and fixes broken symlink problem. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241637 [2] https://bugs.freebsd.org/bugzilla/attachment.cgi?id=209217&action=diff [3] https://svnweb.freebsd.org/ports/head/Mk/bsd.sites.mk?annotate=511849#l496