I did want us to resolve the Wine question though. carving out just that package and its revdep tree would be easy / minimal maintenance and builder load, especially if we drop it as soon as it poses issues or we have a viable replacement and if some of the Linux-centric deps can be dropped. it's just slightly awkward timing – I suspect that CrossOver is going to come out with something during the macOS 27 lifetime given their collaboration with Apple and the Rosetta changes coming in macOS 28. having a period between now and then where macOS users can't get an up-to-date / supported Wine at all feels a bit unfortunate.

it's just a matter of whether I drop the few changes that would need to be elided to carve out a pkgs.wine specifically a la Mesa while keeping everything else behind the error/not-being-built gate. (I could see if we can do it via cross too, which would cut out even more of the support/builds.)

my best guess is

I would vaguely guess that the future for Rosetta 2 looks either like special codesigning exemptions, or there being APIs for running Intel code but you can't have a full-blown Intel Mach-O binary getting loaded normally. we do know that it at least involves some frameworks being able to interoperate with x86 code at least.

maybe leaning towards the latter at this point… I think Apple would love to be able to drop support from the system frameworks and shrink the download. I always read "Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks." as meaning Intel-based .frameworks, but I wonder if "Intel-based framework" is actually a euphemism for "Wine".