[bacon_blood]

No. This isn't fixed by open source. Open source projects also do binary releases (see brew cask), and those need to be universal as well. Someone needs to build those universal binaries, and homebrew has decided to be incapable as a platform to do that by refusing to ship universal binaries.

It is kinda mitigated for end users if you only run an x86 homebrew for the foreseeable future and never compile any software outside of homebrew, but that's a crappy answer.

Universal means you can seamlessly switch between architectures as necessary. Split arch homebrew, however, means you should probably keep one of them entirely out of your path until you need it, as your arch will silently change if you have the wrong arch bin in path (I encountered this in the wild). Having the wrong arch bin first in your path will also result in a bad cpu type error if you force arch on any parent process e.g. with arch -x86_64 (I encountered this in the wild).

Also, users expecting that their build tools will be x86 also results in hacks like checking the cpu type sysctl and forcing ARM, which in any build tool is likely to break the ability to build x86 binaries (I encountered this in the wild in several projects).

I've seen all of this in multiple open source projects. I had to stop using homebrew entirely for build tools as a result.

[bhaak]

Cross-compiling is a need that almost no user ever has.

The only legit need on macOS was for a long time iOS only and now, the two supported CPU architectures. But that is covered by using XCode.

There would be now need for a Apple Homebrew to use or provide universal binaries.

Homebrew's design is for providing tools for the need of the single user of the system (it doesn't even work well in a multi-user environment) with the tools he needs on this system. Switching CPU architecture would be solved with reinstalling Homebrew on the new system (like it is now).

[bacon_blood]

I just checked your profile and it seems like you're a command line software developer for Linux. I'm not sure why you're telling a Mac developer what Mac developers do and don't need, or what use cases are "legitimate".

I'm speaking from personal experience about what is broken about homebrew's developer tools for a software developer building and using lots of existing open source software for Mac. Please don't respond further unless you are absolutely confident your position is in good faith and supported by personal relevant experience.

[bhaak]

Do you think command line software developing for Linux is a paid full time job? My day job is on macOS where I've been using Homebrew for about 7 years.

I know its warts. I don't say that it isn't broken for the usecase you are describing. I'm saying that like the Homebrew developers, if Apple were in charge of Homebrew, they wouldn't care about such a use case because it would only affect a tiny percentage of their user base.

If you don't believe that just look how old the user base command line tools are that are installed by default on macOS.

For example bash is "GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17), Copyright (C) 2007 Free Software Foundation, Inc." That's 14 years ago.

[bacon_blood]

This is a software supply chain issue, but it likely doesn't interest Intel Mac users who are still using x86 homebrew and who can't empathize with the experience of the upstream developers for all the Mac software they use.