MacPorts doesn't respect hard links during install phase

[julien.thewys@…]

Just installed macports and git-core on 10.5 . I can see that lots of generated bin are just the same file:

cd /opt/local/bin;
for i in git-*; do diff -qs $i git-tag; done | grep identical | wc

Some "cp" could be replaced by "ln" in the build process.

[ryandesign@…]

Assign/Cc maintainers.

[blb@…]

git-core does use hard links in the destroot, so the issue is actually with MacPorts base. It currently doesn't look for hard links when going from destroot to install, hence each file is then copied instead of hard linked.

The question is how easy/difficult it would be to detect hard linked files in Tcl, since 'file type' appears to only return 'link' which is a symlink, and 'file' for hard links (since it looks like a file).

[ryandesign@…]

I thought that was the point of hard links -- that they are indistinguishable from real files. So there's no way for base to fix this.

So isn't the fix for the for git-core to install those files as symlinks instead of hard links?

[blb@…]

Replying to ryandesign@…:

I thought that was the point of hard links -- that they are indistinguishable from real files. So there's no way for base to fix this.

It can with inode detection (I think that'd be the simplest way). Something using [file stat...] to detect when a file has more than one link, then organizing those which are the same to keep the hard links.

So isn't the fix for the for git-core to install those files as symlinks instead of hard links?

Perhaps, or maybe they have a reason for using hard instead of symlinks. Also, this could come up again.

[toby@…]

Milestone MacPorts base bugs deleted

[nox@…]

Actually using ln for every hard link from destroot to the image should work just fine. A file with 2 links would just end up with 2 additional hard links in the image.

[nox@…]

Cc Me!

[jmr@…]

This should also have been fixed by r77511.