nix-index icon indicating copy to clipboard operation
nix-index copied to clipboard

Improve handling of derivations that are symlinks

Open infinisil opened this issue 5 years ago • 1 comments

In the current version, nix-locate can't find the libGL.so file in the libGL package:

$ nix-locate libGL.so -w --top-level
primusLib.out                                         0 s /nix/store/qjfnhrq496lw088yw8nkzqz47pbhqkbc-primus-lib-2015-04-28/lib/libGL.so
libGLU_combined.out                                   0 s /nix/store/k9m5fksmz59j1nyyqvxrdxsayi8gynr4-libGLU-combined/lib/libGL.so
libglvnd.out                                          0 s /nix/store/s4akm6sc4lsdrljfpq5m4jp44xmywqjh-libglvnd-1.0.0/lib/libGL.so

I know it worked for some older version, but now it doesn't anymore.

This is probably because e.g. in libGLU_combined, libGL.so is

libGL.so -> /nix/store/11asls7i6l1qz9cm08is75xhgdc1b212-libGL-1.0.0/lib/libGL.so

while in libGL, it is

libGL.so -> libGL.so.1.0.0

So it seems that relative symlinks are the problem.

infinisil avatar Jul 23 '18 22:07 infinisil

This is not caused by relative symlinks. Instead, the problem is that the libGL package itself is just a symlink to libglvnd:

$  file /nix/store/16lxf5c9mh25p380dnzlgz5jnw0v7qdb-libGL-1.0.0
/nix/store/16lxf5c9mh25p380dnzlgz5jnw0v7qdb-libGL-1.0.0: symbolic link to /nix/store/fkgjwjbbj1pccsrrl96fr6mp5bbs5121-libglvnd-1.0.0

nix-index does show this is a symlink (s indicates it is a symlink):

libGL.out                                             0 s /nix/store/16lxf5c9mh25p380dnzlgz5jnw0v7qdb-libGL-1.0.0

So technically the output is correct. But perhaps we should resolve symlinks at the store path level?

bennofs avatar Sep 18 '18 20:09 bennofs