First time fetch in misc/concourse always fails with this message: > fetch: 356525: No such file or directory > fetch: 356525: No such file or directory Running 'make fetch' again succeeds. Log: http://beefy17.nyi.freebsd.org/data/head-i386-default/p549547_s365984/logs/concourse-6.5.1.log The line open-telemetry:opentelemetry-go:v0.2.1:... is repeated 3 times. It was originally printed by ports-mgmt/modules2tuple, and is needed because it is used by different Go sub-projects.
The only way this is related to the framework is Mk/Uses/go.mk. Really it's a modules2tuple issue if anything. Luckily the same person maintains both, assigning to him.
(In reply to Steve Wills from comment #1) But GH_TUPLE should be able to link the same GH project multiple times, regardless of whether this is for a Go port or not.
(In reply to Yuri Victorovich from comment #2) Hmmm, that's arguable. I don't think so, personally and I don't think it was designed to work that way. Having multiple distfiles of the same content seems wasteful when you can use post-extract to copy.
(In reply to Steve Wills from comment #3) Hm, I disagree. Many complex projects now bundle the same dependencies multiple times, just because same projects happen to be used by its different dependencies, via different paths. Manual writing of custom post-extract commands to make up for this seems wasteful because the ports framework "almost" supports this already. It breaks because of what seems to be a small bug somewhere.
(In reply to Yuri Victorovich from comment #4) Are you disagreeing about the wastefulness of multiple copies of the same sources? Go may need it, it may be common, but it's still wasteful IMHO. There's no reason we have to duplicate it. Perhaps modules2tuple can be changed to generate the copy command as it does some of the other things besides TUPLE things already.
(In reply to Steve Wills from comment #5) No, it's not wasteful. It only requires one extra symbolic link to handle. Multiple dependencies occur naturally: 1. ThisProject bundles Project A 2. ThisProject bundles Project B 3. Project A bundles Project C 4. Project B bundles Project C In this situation you need to have two GH_TUPLE lines for C and has nothing to do with modules2tuple. It's wasteful to require to do something systematic manually when it can be automated.
(In reply to Yuri Victorovich from comment #6) Each GH_TUPLE line implies a separate distfile, no? That's the waste I'm referring to. I don't know what symlink you are referring to.
It must be the third or fourth PR you open asking for some strange variation on this subject, please stop. Do it the way we have told you to do it, and please, stop searching for new ways to break ports in this fashion.
(In reply to Mathieu Arnold from comment #8) > It must be the third or fourth PR you open asking for some strange variation on this subject, please stop. No. When I clearly see that I am right, and you are wrong, I will not stop. Instead, I will bring this issue to the public discussion domain. Yuri.