buildEnv fails when merging a directory with a broken symlink

[symphorien]

Describe the bug
buildEnv fails with a misleading error message when a broken symlink conflicts with a directory.

To Reproduce
Steps to reproduce the behavior:

1. create a file test.nix at the root of nixpkgs:

with import ./. { config.allowUnfree = true; };
buildEnv {
  name = "whatever";
  paths = [ clementineUnfree baobab ];
}

2. Run

these derivations will be built:
  /nix/store/9mp5bg8bqkjc2lk890l0glwz5ws2ndkr-whatever.drv
building '/nix/store/9mp5bg8bqkjc2lk890l0glwz5ws2ndkr-whatever.drv'...
Use of uninitialized value $stat1 in numeric ne (!=) at /nix/store/ms37lck4253pfyn4h5kdjxv860cxzp36-builder.pl line 94.
Use of uninitialized value $stat1 in bitwise and (&) at /nix/store/ms37lck4253pfyn4h5kdjxv860cxzp36-builder.pl line 95.
different permissions in `/nix/store/zig3h5zzb7m8rzx1w5z1ppbngip4xs69-clementine-blob-1.3.1/share/applications' and `/nix/store/6x6bhzy9xk1cf7z2k9xl448fm4ypdag1-baobab-3.34.0/share/applications': 0000 <-> 0555 at /nix/store/ms37lck4253pfyn4h5kdjxv860cxzp36-builder.pl line 95.
collision between `/nix/store/6x6bhzy9xk1cf7z2k9xl448fm4ypdag1-baobab-3.34.0/share/applications' and `/nix/store/zig3h5zzb7m8rzx1w5z1ppbngip4xs69-clementine-blob-1.3.1/share/applications'
builder for '/nix/store/9mp5bg8bqkjc2lk890l0glwz5ws2ndkr-whatever.drv' failed with exit code 2
error: build of '/nix/store/9mp5bg8bqkjc2lk890l0glwz5ws2ndkr-whatever.drv' failed

Expected behavior
The broken symlink should be ignored, or a nice explanatory error message should be printed. Notably, it should not be said that the broken symlink has 000 permissions, which is impossible in the store I think.

Additional context
clementineUnfree contains a broken symlink: (will open a PR to fix shortly)

lrwxrwxrwx 2 root root 19  1 janv.  1970 /nix/store/zig3h5zzb7m8rzx1w5z1ppbngip4xs69-clementine-blob-1.3.1/share/applications -> /share/applications

/nix/store/6x6bhzy9xk1cf7z2k9xl448fm4ypdag1-baobab-3.34.0/share/applications:
total 20
-r--r--r-- 3 root root 17353  1 janv.  1970 org.gnome.baobab.desktop

Metadata

• system: "x86_64-linux"
• host os: Linux 5.5.8, NixOS, 20.03beta570.730453919bd (Markhor)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.3.2
• channels(root): "nixos-20.03beta570.730453919bd, nixos-hardware, nixos-unstable-20.09pre216896.0729b8c55e0"
• channels(symphorien): "home-manager-19.09"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: buildEnv
# a list of nixos modules affected by the problem
module:

[stale]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[evils]

seems to still occur, so not stale

[ggPeti]

I now believe this behavior is to be expected. See the reasons that convinced me: #134215 (comment)
On the bright side, when this PR gets merged, the error messages will become less confusing.

[roberth]

I agree that broken symlinks should not be silently removed when they need to be merged with another package's fs node.
Such a situation is best resolved by fixing the package with the broken link. Even if that's not an option for some reason, you can repackage it to remove the symlink.

As said, the messages have improved, so I don't think anything actionable is left.