Have we reached the point of needing a bizhawk-minimal package?

[YoshiRulz]

The download size for BizHawk-win-x64 has doubled since 2.8, now surpassing 80 MiB compressed (see also #3505).
I think that, starting with this next release (2.10.1), we should offer an alternate, stripped-down download option. Since #3937 has stalled, this would have to be in addition to the full build. But compared to the frontend code changes that I suspect will be required, preparing 3 or 4 builds instead of 2 is a trivial matter.

Open questions:

• Which cores to omit?
  • The obvious answer is "the largest ones", which per unzip -v archived.zip | sort -nk3 would mean MAME, DOSBox-X, Encore, and UAE, and that's the download size halved.
  • I'd add that we could also omit the 3 cores planned for deletion, any cores for fantasy consoles (TIC-80, Uzem), subframe cores, and cores which only exist to emulate a few titles (DSDA-Doom, Emu83, PicoDrive, Virtual Boyee...). I haven't run the numbers but that's probably another 10 MiB at least.
• Name?
  • I have some notes from earlier, but tl;dr I'd be fine with the conventional -min suffix.
• Linux? Nix?
  • I don't see why Linux users shouldn't be given the exact same choice. Most of them will be manually downloading still, not that it would be difficult to copy-paste a -min package.
  • The Nix expression can be left as-is. When I get around to finishing unmanaged cores from-source, the override for that can also be used to remove core binaries. Frontend jank is acceptable in that case.

[CasualPokePlayer]

"the largest ones", which per unzip -v archived.zip | sort -nk3 would mean MAME, DOSBox-X, Encore, and UAE

mupen is larger than UAE, if you include all its plugins, with the biggest contributor being GLideN64 (which itself is a must have for the core).

I'd add that we could also omit the 3 cores planned for deletion, any cores for fantasy consoles (TIC-80, Uzem), subframe cores, and cores which only exist to emulate a few titles (DSDA-Doom, Emu83, PicoDrive, Virtual Boyee...). I haven't run the numbers but that's probably another 10 MiB at least.

Combined the cores listed here are less than 5MiB. You're not saving that much by cutting those cores.

[YoshiRulz]

"the largest ones", which per unzip -v archived.zip | sort -nk3 would mean MAME, DOSBox-X, Encore, and UAE

mupen is larger than UAE, if you include all its plugins, with the biggest contributor being GLideN64 (which itself is a must have for the core).

We can hardly omit Mupen though. Maybe we could omit the Rice, Glide64, and Glide64mk2 plugins.

[Morilli]

Excluding largest non-essential cores probably makes sense, the only thing I see as required before making such a release is a system that handles these missing cores gracefully. We can just exclude core dlls from the release but it requires additional work so the user knows what's wrong when such a core fails to load.