diff options
| author | John Soo <johh.soo@arista.com> | 2025-06-04 08:54:47 -0600 |
|---|---|---|
| committer | John Soo <johh.soo@arista.com> | 2025-06-04 10:35:11 -0600 |
| commit | e23b1eba99161848009ae18f65508a87de515715 (patch) | |
| tree | aca7cd5aece677c7090187235dcd70f016d0dd79 /pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch | |
| parent | 4f2be019938169d81d1c95ef75ceb122d9677f68 (diff) | |
pkgs/stdenv: remove --preserve=mode from cp in defaultUnpack
`mode` includes acls and xattrs. Those xattrs can include unsupported
attrs on the destination file system. I.E. If copying from nfs4 to ext
`fsetxattr` can be called with `system.nfs4_acl` which is an
unsupported operation on ext4. This will result in
`cp: preserving permissions for ...: Operation not supported`.
See, for instance:
https://lists.gnu.org/archive/html/coreutils/2024-09/msg00009.html
In our case we saw the following when adding a strace to the cp:
`lgetxattr("/nix/store/ihas6mzn9h54ldgp90pics0yrlmi6ln7-source", "system.nfs4_acl", NULL, 0) = -1 EOPNOTSUPP (Operation not supported)`
Removing this flag should not effect the resulting umask/permission
bits, which I think is all we care about. From the docs:
> In the absence of this option, the permissions of existing
> destination files are unchanged. Each new file is created with the
> mode of the corresponding source file minus the set-user-ID,
> set-group-ID, and sticky bits as the create mode; the operating system
> then applies either the umask or a default ACL, possibly resulting in
> a more restrictive file mode.
https://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html
So the only real problem I can foresee is if the setuid/setgid or
other sticky bits matter to a build. In which case I think an effected
build might have bigger issues.
Diffstat (limited to 'pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch')
0 files changed, 0 insertions, 0 deletions
