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.
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.
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.