Hacker News Reader

Comment by londons_explore | Hacker News Reader

I mostly care if projects don't accept bugfixes. For example "inotify feature longer works with the latest glibc release due to subtle API change" might be an easy 10 line pull request to fix.

But if the maintainer doesn't take the pull request and make a release, then the effort of fixing it is wasted, and every single user has to workaround/suffer from that bug into the future.

There are loads of projects in that state - unmerged PR's from years ago with sensible fixes, no new release, and no forks that are distributed to users.

View on HN

Not to mention this scenario except when it's a security patch that just needs to be applied and released

I wish github and other code hosters made it easier to "just make a release".

Next to the "Download zip" button on github, they should add a "Download built .deb" and "Download built .exe" - and those buttons should work on any fork, branch, PR, etc. And they should add all the necessary build infrastructure to achieve that.

It turns out that at scale, build infrastructure is pretty cheap to run, since caching is so incredibly effective and there is only a need to rebuild a file once per (human) edit to a file or its dependencies.

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

Presumably some kind of Makefile or similar build automation config file would be in the repo to define which versions of which tools to use to do the build.

https://openbuildservice.org/help/manuals/obs-user-guide/cha...

the open build service (by suse) does that. are there others?

I'm certain there are more but I can only think of artifactory now and not sure that even makes the debs (does the repo stuff). Maybe there's a business plan somewhere in there :)

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

Building packages is easy for most programming languages, it's only very old ones and Python that are bad. While I wouldn't expect GitHub to support every language, and many projects will need customization, them offering a basic pipeline for "standard x" for each of e.g. the top 20 languages (other than the awkward ones) would save a lot of effort over every project reinventing its own pipeline.

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.

Reply on news.ycombinator.com