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.
The user adds the repository to the list of repositories their package manager is using,
Fun fact: when we were doing devops as config management, we distributed repository configs AS packages … which we updated as required.
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.
So easy.
These days, with CI, ya berge your patch and the fix is built and sent to testing immediately, ready to be assessed for promotion, which then signs and pushes the artifact into the pipeline for synchronization and application everywhere.
Aside from the actual smarts to build a good package, the tooling makes every other part of is zero-friction.
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.
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.
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.
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.
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.
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 managerNot 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.
Fun fact: when we were doing devops as config management, we distributed repository configs AS packages … which we updated as required.
So easy.
These days, with CI, ya berge your patch and the fix is built and sent to testing immediately, ready to be assessed for promotion, which then signs and pushes the artifact into the pipeline for synchronization and application everywhere.
Aside from the actual smarts to build a good package, the tooling makes every other part of is zero-friction.
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.
Unless you’re Lennart, it’s a bad idea.
yes i was. didn’t get great sleep, my bad.
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.
Harbottle does this. It’s very well-done.
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.
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.
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.
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.