setup.sh: verify that find is from findutils

[ghost]

Description of changes

PR #168413 causes setup.sh to use find. Packages which put busybox into their nativeBuildInputs will have $busybox/bin/find ahead of $findutils/bin/find in $PATH when setup.sh is run, causing setup.sh to fail.

Let's check that find is really from findutils so we can provide a more useful error message.

The setup.sh script already does a similar check to make sure that the shell it is running under is bash rather than some other shell.

A longer-term solution to the problem of busybox's outpaths conflicting with stdenvs is described here:

#177682 (comment)

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.11 Release Notes (or backporting 22.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[Mindavi]

shellcheck is a tool to verify if shell scripts are valid, it's unrelated to checking if the correct shell is used.

[ghost]

:embarrassed:

[Mindavi]

Could there be reasons for people to want to use find from busybox? This seems quite strict, though I understand where you're coming from.

[alyssais]

What features of GNU findutils do we need that Busybox's find doesn't have? Would it be possible to make setup.sh compatible with both?

[Mindavi]

Hmm, I thought it was abuild that was expecting find with printf. I don't see -printf in the fixLibtool PR.

So putting it here may be at the wrong layer, but not sure where to put it then. And I agree we don't want conflicting binaries in stdemv regardless.

[ghost]

What features of GNU findutils do we need that Busybox's find doesn't have?

Just -execdir, which I used out of habit. It isn't needed here because TOCTOU attacks on nix's builders' temporary directories (/tmp/nix-build-*) shouldn't be possible.

Could there be reasons for people to want to use find from busybox?

I'm not sure. But it can't hurt.

Would it be possible to make setup.sh compatible with both?

Sure: #177789

[ghost]

Hmm, I thought it was abuild that was expecting find with printf

It's the -execdir that busybox find doesn't like.

And I agree we don't want conflicting binaries in stdemv regardless.

I am certainly on board with using the minimum features needed for the task, so I'm switching this to -exec. But yeah in general I hope this isn't seen as encouraging people to expect that nixpkgs will work effortlessly if they swap out pieces of stdenv for alternatives with different feature sets. Like say the OpenBSD userspace versions of all our GNU tools... that would definitely break a lot of stuff.

[alyssais]

It would be really nice if build inputs looked at meta.priority, IMO. There are other situations where it'd be nice — e.g. I have a shell.nix with both virtiofsd and qemu, and I have to make sure to specify them in the right order so I don't get QEMU's deprecated built-in virtiofsd ahead in PATH.

[ghost]

It would be really nice if build inputs looked at meta.priority

Hrm, is that possible?

I thought that changing a package's meta would not affect its drv-hash (or the drv-hashes of packages which depend on it).

If builders could see their inputs' meta.priority then changes to meta.priority would affect the build process, and therefore would have to affect the drv-hash.

[ghost]

Also while we're wishing for things, I wish meta.priority were a partial ordering rather than a total non-dense-ordering.

So for any given package you can add a list of other packages it is strictly-less-than (or strictly-greater than). No integers to remember and no running out of priority levels between e.g. "5" and "6".

I can never seem to remember integer priority systems like the one in nftables.