This has been the norm for awhile. No one wants to work with distro maintainers because their model is incompatible with how people build and distribute their software.

You either get a curl sh, a tarball, or a wrapper around either of those that pretends to be a .deb or .rpm.

I've distributed a lot of software and DEB/RPM has to be the worst. I'd suggest those distros improve on their developer ergonomics if they want to stay relevant. 100% of my customers use Docker images these days as it is much much easier to use.

Someday someone will make a hyper-package-managers to be able to manage their packages installed via the thousands of package-managers out there today. Then, several other hyper-package-managers will be developed to cover the cases the first didn't cover. Then comes the hyper-hyper-package-managers...

Hasn't it always been rare for developers to maintain distro specific packages? That's why distro's have package maintainers, they also modify the layout and default configurations and whatnot to be consistent with the rest of the distro.

Go binaries are statically-linked, and this tool doesn’t require any configuration files or other additional files.

Binaries are provided on the Releases page, so all you need to do is download one, put it in /usr/local/bin, and it’s essentially guaranteed to work.

To upgrade, you download the new release and overwrite it.

There’s an argument to be made for not having the version information available for dependency resolution (for scc as a dependency) available in your package manager, but you have to admit that it’s easy enough to install. GitHub doesn’t even mind if you `wget && chmod` from their CDN URL.