Change:
haskell = super.haskell // { compiler = recurseIntoAttrs super.haskell.compiler; }; <ins> # minimal-bootstrap packages aren't used for anything but bootstrapping our # stdenv. They should not be used for any other purpose and therefore not # show up in search results or repository tracking services that consume our # packages.json https://github.com/NixOS/nixpkgs/issues/244966 minimal-bootstrap = { }; </ins> }; }

Discussion:
The package set's goal to provide an opaque replacement for in the stdenv. The chain to get from the seed binary to that point includes many packages that may be outdated, insecure, or contain broken/missing features. In addition the research into bootstrappable builds is always evolving, and we may want to add or remove packages into the internal dependency chain without guarantee of stability. These packages are not intended to be used directly by end-users. Tools (such as , repology, etc.) currently index this package set and provide discoverability to users. Trying to use these packages in the real world will currently most likely fail, warning you that the only supported platform is . However a more robust conditional check with better errors and documentation could be implemented to limit accidental use. Another potential minor annoyance might be vulnerability scanning tools detecting the use of old package versions deep down in the stdenv bootstrap and triggering a false-positive. There are some tools that evaluate this package set that we do want to keep working. An important example would be Ofborg's eval checks and maintainer pings. Adding a flag that guards usage of the package set with explanation and background information in an error message. Renaming to something in a similar spirit to I came up with two potential improvements but neither would completely solve all the issues. I'm very interested to get everyone's ideas and comments to work together for a solution.
Related
I think I would just create a new field, and then ask other tools to respect it. See also which would give Nixpkgs more direct control over the JSON Repology gets, rather than hoping does what we want.
(I liked the original title better; Nix has a culture-specific redefinition of what "RFC" means, and an entire baroque process for doing them). Honestly this sounds like a problem with Repology, not Nixpkgs. Easy solution: don't expose it as a top-level entry in . Make it private to (which is where we should consider moving it once we are ready to make the switch).
I would not like to just put in because I have long wanted to separate "bootstrapping" and "the standard environment" as two independent concepts.
Ah, I see. Okay, sounds good.

My point was that needs to reference the result somehow, and that we can keep that reference "private" by not having it detour through (or its successor, , now that the RFC is merged).
Search and Repology use the we export as part of the channel tarballs. What's listed in the JSON is what they will show. I think the solution to this issue is simply to not recurse into the set; removing its attrs from the JSON. There's two ways of doing that: the in all- it with in 1. would stop recursion for all tools making use of nix-env to generate the whole list of packages in Nixpkgs including tools such as ofBorg, nixpkgs-review and while 2. would only affect tools consuming our generated packages JSON.
Yeah is fine.
would you be able to make a PR for 2 please? It sounds good, I'm just not 100% confident I understand enough to implement it right myself