Well, linux doesn't have adhoc package management.
Because there is no standard packaging format between distributions, the best people can do is release a deb that may or may not work on either debian or ubuntu. Or an RPM that may or may not work on RH/Fedora. Or a tar.gz that will contain sometimes source code, sometimes a binary, and if it has source code there's no clear way to compile it, if it has a binary there's no clear way to install it.
So instead, curl sh.
It's pretty ridiculous that it's still a problem, tbh. What we need is somebody with the right political clout at either RH or Debian to sit down with devs of the other, come up with a decently generic solution that fits both systems and a backwards compatibility policy. It doesn't have to be perfect nor the best, it just has to be good enough to support the use cases of most Linux distros.
Once both Debian and Fedora support it, Ubuntu (and its many flavors) and Red Hat will follow. And if it's a generic enough system, with a pluggable-enough backwards compatibility policy, it's not unlikely for it to be adopted in more minor distros. If it's sold correctly, distros will gladly adopt it - we've all been waiting for this a long time.
I guess I do not understand the manner in which you use "ad hoc" to refer to package management.
It seems as though you are now talking about cross-distribution package management. It is further confusing that you are contrasting all "Linux" to the single distribution macOS.
To me the term is "ad hoc" current w.r.t. NixOS , GNU Guix and other purely functional systems, and there the distinction is made between:
1) declarative -- in which a rebuild of the system will ensure the package is present and configured as expected; and
2) ad-hoc -- in which the user can affect all of the system with side effects and rebuilds will not result in the same state.
Why would you want to allow users to randomly and aribitrarily affect all of the system and end up in an unknown state? Isn't that exactly what curling shell scripts achieves? And what method does macOS implement in order to avoid this?
If all you're talking about is cross-distro package management then you and your users can either give up on this and standardize on one OS and just pony up the cash for RedHat (same as you do for macOS) or else start writing Flatpaks.
Because there is no standard packaging format between distributions, the best people can do is release a deb that may or may not work on either debian or ubuntu. Or an RPM that may or may not work on RH/Fedora. Or a tar.gz that will contain sometimes source code, sometimes a binary, and if it has source code there's no clear way to compile it, if it has a binary there's no clear way to install it.
So instead, curl sh.
It's pretty ridiculous that it's still a problem, tbh. What we need is somebody with the right political clout at either RH or Debian to sit down with devs of the other, come up with a decently generic solution that fits both systems and a backwards compatibility policy. It doesn't have to be perfect nor the best, it just has to be good enough to support the use cases of most Linux distros.
Once both Debian and Fedora support it, Ubuntu (and its many flavors) and Red Hat will follow. And if it's a generic enough system, with a pluggable-enough backwards compatibility policy, it's not unlikely for it to be adopted in more minor distros. If it's sold correctly, distros will gladly adopt it - we've all been waiting for this a long time.