Hello! Ricardo Wurmus <rek...@elephly.net> skribis:
>> Would it be possible to add an option to retrospectively apply this >> transformation? Maybe that could work somewhat like this: >> >> $ ls -lha >> ... /home/me/projects/mrg1_chipseq/.guix-profile-1-link -> >> /gnu/store/ap0vrfxjdj57iqdapg8q83l4f7aylqzm-profile > > This wouldn’t work, because we can’t read > /home/me/projects/mrg1_chipseq/.guix-profile-1-link centrally. In > this particular case only the user “me” could resolve the link and > thus migrate the link. (I would do this semi-manually by > impersonating the users to read their links.) > > ~ ~ ~ > > Another related problem I found is that the names of the links in > unreadable space may have names that only make sense on the system > where they were created. For example, on the server “beast” we may > mount the cluster home directory as “/clusterhome/me”, whereas on > cluster nodes it would be mounted as “/home/me”. When I have Guix > record a gcroot while working on “beast” I would get a link that is no > longer valid when I work on the cluster. To me these are “documented limitations”. User home directories must be visible to the head node where guix-daemon runs, or GC won’t see all the roots. It seems hard to avoid. Though an admin could decide that only ~/.guix-profile matters, and in that case the head node only needs to be able to access /var/guix/profiles (a restriction that may be acceptable in practice: users need to restrict themselves to ~/.guix-profile and ‘guix environment’). But yeah, I agree these are gotchas and it’s easy for a cluster admin to shoot themself in the foot. Thoughts? Ludo’.
