Core system package managers (apt etc) handle security issues quickly and in collaboration with security researchers and authorities. They have far more manpower, experience and connections than brew.
Bleeding edge is handled by rolling package managers, and these often build automatically from source as soon as a commit is tagged.
I don't see a clear reason to use brew, which does everything a little bit worse. In fact, I see it as a red flag in projects since it usually indicates lack of first class Linux support.
> They have far more manpower, experience and connections than brew.
And Homebrew’s maintainer team, in turn, has far more of all that than the average Flatpak app developer has, which your earlier comment suggested as an alternative to Homebrew.
> I see it as a red flag in projects since it usually indicates lack of first class Linux support.
In most distros, upstream projects have very little say in whether or not the distro is going to include them.
It’s the distro maintainers who make that decision, and it depends on many different factors, some of them outside of the upstream project’s control, but none of them related to „first class Linux support.“
For example: is the upstream license an acceptable fit for the distro? How many dependencies does it have, and are those already available as packages in that distro? Does it make technical assumptions that clash with the distro’s assumptions? Has anyone stepped up and authored the package yet? And so on.
Never have I seen “lack of first class Linux support” as a scale-tipping argument against including a particular package in a distro.
Bleeding edge is handled by rolling package managers, and these often build automatically from source as soon as a commit is tagged.
I don't see a clear reason to use brew, which does everything a little bit worse. In fact, I see it as a red flag in projects since it usually indicates lack of first class Linux support.