Earlier quoted context omitted.
> we got things like flatpak, appimage directly from developers Some people prefer timely, high-quality, well-tested bugfixes and security updates for the underlying low-level dependencies of an app. An upstream app developer is much less likely to provide an updated flatpak mere minutes after e.g. a critical OpenSSH security fix comes out of embargo. Distro maintainers on the other hand, such as the Homebrew core ma…
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 f…
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.