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.

I’m pretty sure that, with a bit of fiddling, you could even put them on a github pages site.

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.

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.

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.

How does it lead to dependency hell? I thought the point was that it didn’t share dependencies with the host, so different apps could have different versions of the same package and everything would still work.

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.

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.

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.

that defeats the purpose of a package manager

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.