Nineteen distribution channels later: what it actually costs to give a terminal editor away for free on Linux, and why the next step is a static musl binary that updates itself.
The author seems to have completely missed the point that they can just publish their own repositories to allow users on both of these platforms to update. It would also mean they could avoid the problems they’re having building source packages.
Their complaints about supporting instalations with older libc versions are also addressable by just building against the oldest libc they wish to support.
You can put the repositories on pretty much any static hosting. I haven’t tried it, but I’m pretty sure that, with a bit of fiddling, you could even put them on a github pages site.
Both distros have good tooling for maintaining repositories, and I’d say it’s probably easier than getting your package into the official repos and keeping it updated there, especially on distros like Debian which favour stability over having the latest versions of packages.
No distribution system is going to be entirely friction free for the author, but I’ve not encountered any significant issues hosting deb or rpm repos.
I don’t see the problem. For years I’ve used the public Open Build Service instance at openSUSE to package and publish software for openSUSE and Fedora (never cared for Debian/Ubuntu because I packaged the software only for my own use but it’s possible).
I know right? This is literally what flat pack was meant to address. Just package has push it and let any system use it. So it is a little more complicated and another step on top of everything.
This is literally what flat pack was meant to address. Just package has push it and let any system use it. So it is a little more complicated and another step on top of everything.
Flatpak is absolutely terrible. As a second repository, it breaks source of truth, doesn’t share dependency or SBOM data with the system and at worst begs for dependency hell.
I suspect you’re confusing the package manager with the supply chain. This should always be separate, lest we get some systemd-like spongiform blob with no ability to swap out and improve parts without discarding the whole.
The author seems to have completely missed the point that they can just publish their own repositories to allow users on both of these platforms to update. It would also mean they could avoid the problems they’re having building source packages.
Their complaints about supporting instalations with older libc versions are also addressable by just building against the oldest libc they wish to support.
i guess the problem with that is having to maintain the repository setup. they’re basically web servers with signed files.
That does solve one problem at the cost of a bunch of other potential problems.
You can put the repositories on pretty much any static hosting. I haven’t tried it, but I’m pretty sure that, with a bit of fiddling, you could even put them on a github pages site.
Both distros have good tooling for maintaining repositories, and I’d say it’s probably easier than getting your package into the official repos and keeping it updated there, especially on distros like Debian which favour stability over having the latest versions of packages.
No distribution system is going to be entirely friction free for the author, but I’ve not encountered any significant issues hosting deb or rpm repos.
Harbottle does this. It’s very well-done.
I don’t see the problem. For years I’ve used the public Open Build Service instance at openSUSE to package and publish software for openSUSE and Fedora (never cared for Debian/Ubuntu because I packaged the software only for my own use but it’s possible).
I know right? This is literally what flat pack was meant to address. Just package has push it and let any system use it. So it is a little more complicated and another step on top of everything.
Flatpak is absolutely terrible. As a second repository, it breaks source of truth, doesn’t share dependency or SBOM data with the system and at worst begs for dependency hell.
At best it’s XKCD 927.
that defeats the purpose of a package managerI suspect you’re confusing the package manager with the supply chain. This should always be separate, lest we get some systemd-like spongiform blob with no ability to swap out and improve parts without discarding the whole.
Unless you’re Lennart, it’s a bad idea.
yes i was. didn’t get great sleep, my bad.