@gartung I'll have a look at this asap. Also, while reading the code in spack.relocate I'm trying to get some basic tests for that. I'll ping you for a review when ready to submit a PR.

The tests that can be done without binaries are already in packaging.py. I might be able to add a test for get_normalized_elf_rpaths to packaging.py which would have caught the bug with $ORIGIN not getting replaced correctly.

I hope this is fixable because I spent way too much time getting it to work and then had to drop it from the other PR because I couldn't figure what broke.

It looks like the error occurs because no build_stage is configured.

I used the mock_stage fixture with the nomockstage keyword.

I needed to add build_stage and connect_timeout config settings to get this to work,

Unit tests should not install real packages. I'm going to have to revert this. I have added #15646 to do so and will be merging it ASAP. We can talk about how to achieve the same result without installing real packages later.

Note that PR also explains why unit tests shouldn't install real packages and provides an example of how that can cause our unit tests to fail for unrelated PRs

Would it be possible to store small tar files of an already built package and unpack that into an install prefix instead? I am thinking of the corge, quux and garply dummy cmake packages that Jim Amundson made to demostrate spack-dev functionality. The buildcaches for these packages are really tiny.

That could work: I'm assuming this means that all the code for the packages is present and doesn't need to be downloaded by Spack.

Fetching is probably the main issue. The amount of time it takes to compile the packages is not a big deal. Actually running the compiler may arguably introduce fragility, but in Spacks case it might be useful to run it where available.

One issue: if these packages actually need CMake to run, then installing CMake as a prereq of doing the unit tests may be problematic (unless we can get the cache to share across all unit test runs).

The other time consumer is running file on every file in the package to determine its type.

I propose building them and creating tarballs from the install prefix to be stored in the test/data directory. The install would be mocked up to unpack the tarballs into the correct directory and maybe using patchelf to set the initial rpaths in ELF files. The mock package definitions would not need a dependency on cmake.

Would it be possible to run a script in Github Actions and capture the coverage from running spack buildcache create commands?