@Ericson2314 this seems to have broken some arm build again. Any ideas?
https://github.com/NixOS/nix/actions/runs/3987622004/jobs/6837814554

checking for rapidcheck/gtest.h... no
checking for  in -lrapidcheck... no

on the master version too. So that's worth investigating.

We should avoid backports like this. This adds a required dependency which is not what people expect in a point release. The backport should only include the actual bug fix.

It does contain a fix, re-adding digits to the allowed output names.
It's not a trivial revert, but we could remove the test dependency. Personally I wouldn't bother this time, because we haven't produced a valid release for Nixpkgs yet, and there's the potential benefit of making future backports easier, if they have property tests, but I'll keep it in mind for future backports.

I think it is good to note that if one does doCheck = false, there is no added dependency added in principle.

The point is that making invasive, potentially destabilizing changes on master (like adding a new test framework) and then immediately backporting them to the maintenance branch defeats the whole purpose of the maintenance branch. We should not get in the habit of just adding the "backport" label to big PRs.

(For instance, this did break the coverage job, leaving the maintenance branch in an unreleasable state.)

Fair enough. I do think this would be a non-issue if we emphasized CI instead of release management, but we don't have to modernize everything this week ;)

I've opened #7687

emphasized CI instead of release management

Not meaning to say release management isn't needed, just that this wouldn't be much of a problem if the testing was actually continuous. I'm all for good habits, whether it's testing or release management.

It's not really a CI issue. Downstream packagers probably also don't expect point releases to introduce new dependencies.

And of course we do have a CI for this, namely Hydra.

I wouldn't call that continuous, and downstream hasn't completed packaging the minor version yet. But I agree that we generally shouldn't rely on such an assumption. That's why I've opened #7687, even this time.