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.
Not really. The user adds the repository to the list of repositories their package manager is using, and the packages in that repository appear as normal packages for them to select. When the author publishes a new version of their package it’ll appear as an update in all users package managers.
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).
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.
Sort of, but each of them uses a different way of making the repository, so really it’s more a case of different repositories in different directories, but they can all be on the same website.
It does sound a bit daunting to begin with, but the process is actually fairly straightforward, and once you understand it, publishing your package to your repositories just becomes another step in your build pipeline.
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.
To be fair, he does address why flatpak isn’t really suitable for his package in particular, as it needs to get out of the sandbix flatpak puts it in, which is hacky. None-the-less, it does feel like he’s making a mountain out of a mole hill.
Ah that’s fair yeah. It’s getting better. But without some sort of system where a flat pack can request the permissions that it needs at install or runtime. It’s far from where it should be. Trivial to do with an app like flat seal. But that’s not typically installed out of the box. It’s all command line by default and very obtuse to the average user.
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.
that defeats the purpose of a package manager
Not really. The user adds the repository to the list of repositories their package manager is using, and the packages in that repository appear as normal packages for them to select. When the author publishes a new version of their package it’ll appear as an update in all users package managers.
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.
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).
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.
Can’t you just put all your packages in the same repository but different directories? Example: debian/.deb, fedora/.rpm, appimage/appimage…
Sort of, but each of them uses a different way of making the repository, so really it’s more a case of different repositories in different directories, but they can all be on the same website.
All of that sounds unintuituve and complicated, which I think is the main complaint overall.
It does sound a bit daunting to begin with, but the process is actually fairly straightforward, and once you understand it, publishing your package to your repositories just becomes another step in your build pipeline.
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.
To be fair, he does address why flatpak isn’t really suitable for his package in particular, as it needs to get out of the sandbix flatpak puts it in, which is hacky. None-the-less, it does feel like he’s making a mountain out of a mole hill.
Ah that’s fair yeah. It’s getting better. But without some sort of system where a flat pack can request the permissions that it needs at install or runtime. It’s far from where it should be. Trivial to do with an app like flat seal. But that’s not typically installed out of the box. It’s all command line by default and very obtuse to the average user.