Hacker News Reader

Comment by kyrofa | Hacker News Reader

Oof, yeah that's painful. I'm impressed you've gone to these lengths, most maintainers don't do that. They generally rely on the folks who want to use the software packaging it for their distros. Obviously there's a bit of a chicken and egg problem there, though, if you care about getting your software in front of users.

For the Debian situation specifically:

> It would've been nice if there was a quick serverless solution where you could just say a URL to look for newer versions of a single package, and both apt and dnf would remember that and update a package.

Have you considered just hosting your own Debian repo? It's basically what you're looking for here. You don't need more infrastructure, either, you can host them straight in github pages with aptly or reprepro or something, and drop new releases in there from CI.

View on HN

> Have you considered just hosting your own Debian repo?

There are Canonical PPAs for that, which make distribution much simpler (it's still not as simple as it could, but with AI's help it's simple).

Of course. Needing to ship a source package (as PPAs require) may actually complicate things, though.

The software referenced is open source and it's already packaged to deb (see home page), so setting up the boilerplate for PPA submission (via AI) is very easy.

If a package doesn't have particular build requirements, setting up a PPA is overall simpler than hosting a personal repo (I do both).

To be clear, I'm not trying to argue or disagree with you. I agree that PPAs are a fine option. I'm not trying to disparage them, I'm trying to explain the reasoning behind my suggestion: PPAs enforce a number of requirements that exist for a reason, but that can be a challenge to meet depending on the project. The biggest example is that of source packages. I don't mean "your source needs to be open" (which of course this project is), but rather "your software needs to be built on Launchpad infrastructure." If you take a look at the existing CI the maintainer has in place to build the binary deb, you'll see what I mean: https://github.com/sinelaw/fresh/blob/master/.github/workflo... . The maintainer already has this, and it would need to be completely re-done to make it work in Launchpad, and the amount of work might be quite significant. A standalone Debian repo can just have binary debs, i.e. the work that has already been done can continue being used.

Thus my recommendation for aptly/reprepro: it's a more natural extension of what the project already has in place rather than a "you should do this instead."

I do publish deb files in the GitHub release page. Will take a look at aptly / reprepo

Yeah, the one thing you're missing is getting into the users' `apt update`/`apt upgrade` flow, right? This will get you there without needing to change the Debian package you already create (although you can ship different ones this way if e.g. older Ubuntu/Debian distros require it and you want to support them).

Reply on news.ycombinator.com