BUG: coreutils/diffutils/m4 +with_default_names installation fails

[vinc17@…]

I tried to install coreutils with the with_default_names variant and got the following error:

Error: Target com.apple.destroot returned: could not create new link "[": that path already exists
Warning: the following items did not execute (for coreutils): com.apple.activate com.apple.destroot com.apple.archive com.apple.install

[vinc17@…]

Same problem wit diffutils:

Error: Target com.apple.destroot returned: could not create new link "cmp": that path already exists
Warning: the following items did not execute (for diffutils): com.apple.activate com.apple.destroot com.apple.archive com.apple.install

[vinc17@…]

Also, though I can't try, it seems that these ports forget to add links for the man pages in the with_default_names variant.

[pipping@…]

Also, though I can't try, it seems that these ports forget to add links for the man pages in the with_default_names variant.

that wasn't intended. there's no reason to move the manpages

could not create new link "[": that path already exists

the old links from +normal-install-names still exist. they aren't removed upon uninstallation. i could make sure whatever there is is overwritten - some package provided md5sum, e.g., too, so how should that be dealt with?

[vinc17@…]

that wasn't intended. there's no reason to move the manpages

There's a good reason: to have the man page associated with the command. In fact, I'd like the with_default_names variant to use the latest coreutils version only (not the one provided by Mac OS X). So it is normal to get the latest version of the man pages too. Using "man gls" is a workaround, but I'd like to completely ignore gls and so on. Moreover the man command can also be used in scripts, e.g. under zsh, typing "ls" then invoking run-help will run "man ls".

the old links from +normal-install-names still exist. they aren't removed upon uninstallation.

This is bad. Anyway this doesn't explain the bug since I've never used +normal-install-names (I had a script that installed symbolic links in /usr/local -- note: /usr/local, not /opt/local). For instance:

prunille:~> where [
[: shell built-in command
/usr/local/bin/[
/bin/[

[pipping@…]

i've taken care of the naming issue in r22431.

no idea how come you have a file '[' in /opt/local/bin.

[vinc17@…]

no idea how come you have a file '[' in /opt/local/bin.

I don't have one. So, I don't know why port complains. Ditto for the diffutils port: I get an error concerning cmp, though I don't have a /opt/local/bin/cmp file.

BTW, the error is in destroot. At this time, files in /opt/local/bin shouldn't matter anyway.

[vinc17@…]

Same problem with m4.

[pipping@…]

welll... i can't reproduce this, hence i can't fix it.

my advise is not to use the variant.

[vinc17@…]

Upgrading to MacPorts 1.4 rc2 solved the problem (at least for m4). Which MacPorts version did you use?

[pipping@…]

i'm using the latest version from the trunk.

[vinc17@…]

This explains you didn't get any problem. The bug seems to be in MacPorts 1.3.2, but this will no longer matter once MacPorts 1.4 is released.

[pipping@…]

so, can i close this ticket?

[vinc17@…]

Problem fixed in the future MacPorts 1.4.

[(none)]

Milestone Port Bugs deleted