-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid symlinking to /bin when building singularity containers (or warn on clashes) #93122
Comments
I think this is a good idea, it's a cleaner solution. However, changing to path manipulation won't really change the masking situation, the order will still matter. |
thanks @jbedo! I realize the masking issue isn't fixed by this, I probably should have separated out the two issues. I'll try to put together a PR in the next couple days. |
I marked this as stale due to inactivity. → More info |
It is still important to me. |
@ShamrockLee which bit, the warning on masking or using path instead of symlinking? |
Using PATH. |
How about constructing a |
Can you share your WIP so I can take a look? |
@jbedo Here. https://github.com/ShamrockLee/nix-singularity The container is built with The remaining part is the still the same as those in nix-docker, where they were forked. |
I marked this as stale due to inactivity. → More info |
Somewhat related to #93082.
Presently when building singularity images, the
contents
(derivations) paths of the container are traversed, and each file found in$content-n/bin
are symlinked to /bin.https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/singularity-tools/default.nix#L80
The relevant code is:
In the case multiple contents have the same binary the first is used and subsequent are skipped.
I think it would be preferable if we used $PATH instead of symlinking to bin. To accomplish this we could instead traverse the contents appending their paths and write that to a file in
.singularity.d/env
settingSINGULARITY_PREPEND_PATH
in e.g.env-nix.sh
. This ensures the nix$PATH
s precede the defaultPATH
.Alternatively, if this seems like too much work for not enough gain, issuing a warning in the above for loop when an executable is masked would be advantageous for users.
@jbedo what do you think?
The text was updated successfully, but these errors were encountered: