Both ports install a pair of identical executables: ${PREFIX}/lib/${port}/${port} and ${PREFIX}/lib/${port}/${port}-bin. For example: -rwxr-xr-x 1 root wheel 532976 Jul 12 13:28 /opt/lib/firefox/firefox -rwxr-xr-x 1 root wheel 532976 Jul 12 13:28 /opt/lib/firefox/firefox-bin -rwxr-xr-x 1 root wheel 708872 Apr 18 22:47 /opt/lib/thunderbird/thunderbird -rwxr-xr-x 1 root wheel 708872 Apr 18 22:47 /opt/lib/thunderbird/thunderbird-bin If one of them is not actually used, then it should not be installed at all. If both are used (due to bugs in upstream scripts), then the two incarnations ought to be made a hard link.
This is a decade-old upstream bug, and they're not that interested in "fixing" it. This setup is intentional and thus not a good idea to only have one or the other.
> This setup is intentional and thus not a good idea to only > have one or the other. This seems to imply, both incarnations are used by different programs... Ok, then making them one with a hardlink will save not only diskspace, but also runtime RAM... Do you need a patch?
I would take it up with upstream, in the linked bug. It is a matter of hard-to-track heisenbug breakages that continue to necessitate this setup.
> It is a matter of hard-to-track heisenbug breakages There is no possible way for the proposed method -- making two binaries a hardlink -- to break anything...
(In reply to Mikhail Teterin from comment #4) As far as I can see, pkg doesn't really support hard links. And with some further thinking: do we even guarantee a file system with hard link support? Think NFS - that's a whole can of worms on it's own - which some poeple seem to use for their /usr/local. And then: we're talking about a few hundred kB in a 200MB install size port. I'm not going to spent any more time than this note on that.
(In reply to Christoph Moench-Tegeder from comment #5) > pkg doesn't really support hard links. Huh? There are NUMEROUS multi-link files under $PREFIX, installed by different packages, including git, llvm, and portupgrade. Moreover, man-pages have been installed as hard-links for DECADES, including man-pages of the ports. Try: find /usr/local -type f -not -links 1 libexec/git-core/git, in particular, has 138 hardlinks here! > further thinking: do we even guarantee a file system with hard link support? I suppose, if one were to host $PREFIX on FAT floppy, things might break, yeah. But then, he wouldn't be able to install git either -- and thus, have no /usr/ports to begin with :-) > Think NFS - that's a whole can of worms on it's own NFS certainly supports hardlinks and has since its earliest versions. > we're talking about a few hundred kB in a 200MB install size port The actual gain is not relevant. But this is the attitude, which explains why, despite enormous progress of the hardware, the "computing experience" is lacking, and gigabytes are becoming necessary, where megabytes were sufficient earlier. > I'm not going to spent any more time than this note on that. Thank you, that's a comforting promise, actually.
Created attachment 226519 [details] Symlink ${MOZILLA} to ${MOZILLA_BIN} Symbolic links may be even better here -- and Mozilla-ports use them already. But removing the `s` flag will make for the hardlink.