Making a .deb isn't as simple as it might seem. If you want to use shared libraries, especially so. Which version of Ubuntu/Debian/Mint/... whatever are you targetting? You can tools like FPM[1] (which is awesome btw, used it for some great hacks in the past), but that won't make you .debs that are necessarily done to the debian guidelines but usable.

There are a load os SaaS companies that do that allow you to make multiple targets though, so perhaps some integrations there would work.

[1]https://github.com/jordansissel/fpm

When making a github release, you can attach whatever file you want, including .exe and .deb. The problem is that building packages is kind of a nightmare, as there's at least one (or, as is the case far too often, many) build system for each programming language. Linux package management is also hard as each distro has its own way of packaging things. And you need a mac to produce macOS Applications...

My point is, there is no way github could add a fully automatic "build and package this release" button. It would require tons of configuration (and trial and error...) from the user.

But good news! If you _are_ willing to figure out how, you can make a github pipeline that compiles and packages your code (producing an "artifact"). Several projects I follow do exactly this. A complex problem like this essentially requires a bespoke solution, and to be fair github does give you tools to automate said solution. The problem is not the infrastructure but the complexity of build systems.

I do agree there should be more ready-made pipelines to aid this process. When I tried to release a python program to work on linux, windows, and macOS, I quickly realized I wasn't interested in figuring out how to make a working pipeline (after spending a weekend getting it to build on each OS in the first place). But surely that's because python is particularly bad at package management... Well, most languages are particularly bad at it

That sounds more like papering over the cracks of legacy systems, introducing even more centralisation and power to a handful of unaccountable "hosters", and placing even more responsibilities on maintainers (who may be AWOL).

- Cryptographically-verified, content-addressed storage (e.g. IPFS) is preferable to downloading random EXEs from "github and other code hosters". Indeed, for sources too! (I learned this lesson when Microsoft bought GitHub, and many projects jumped ship; that caused an outbreak of 404s for anything that was hard-coding github.com URLs!)

- Rather than relying on someone else having produced opaque blobs for us, it's better for everyone to be capable of building things, if needed. Nix (and Guix) are good for this, since they're source-based, ensuring that the full build instructions are available (they will automatically download binaries, if available and signed by a trusted key; but the option of building ourselves is always there). This is also crucial if we want to validate those binaries for ourselves (I recall the "trustix" project is trying to crowd-source such validation too)

- Another advantage of the Nix/Guix approach is that build instructions can be parameterised, e.g. by the source. This allows anyone to plug in any version of the code they like (whether a git commit, or a local folder, or an IPFS URL, etc.). Again, if someone else has already built that combination (and someone we trust has signed it) then their existing binary will be fetched.

This sort of approach doesn't require any buy-in from hosting platforms, maintainers, DNS authorities, etc.