Your options are reduced to the following:

Flatpak

Linux only package manager that works across distros. It supports sandboxing via bubblewrap, but be cautious because by default most programs in Flathub are not as sandboxed as they should. You can host your own repository but it is heavily centralized towards Flathub, controlled by Red Hat, IBM.

Flatpak uses OSTree to distribute and deploy data. The repositories it uses are OSTree repositories and can be manipulated with the ostree utility. Installed runtimes and applications are OSTree checkouts.

AppImage

You’re basically packaging your program and every single dependency up to the C library. Linux only.

An AppImage is basically a self-mounting disk image that contains an application and everything the application needs to run on the target systems

source (incredibly biased towards AppImage)

Snap

Canonical’s take at flatpaks. They are quite similar, but snaps use AppArmor instead of bubblewrap and the server is proprietary, so an inferior option and should be avoided. The only “advantage” is that it’s used by default in Ubuntu.

Nix/Guix

multi distro package manager with reproducible builds support, more akin to a traditional package manager (eg apt)

Snappy and Flatpak talk about how they make library versions work better together and blabla and how they solve a lot of issues but that’s just a praetext, the real elephant in the room is that they are a big wink to proprietary software, they were designed for that, they just can’t say it so they focus on other things in their PR statements.

How Nix and Guix work is that they are traditional “package managers” as such the user or the distributor must have access to the source code to compile it into a package, the interesting difference is that it is capable of keeping library versions apart and will automatically share libraries if they are exactly the same. But packaging still occurs downstream, not upstream.

Snappy and Flatpak allow packaging to occur completely upstream at the developers side, which means they no longer have to cough up source code to whomever who will package. Which leads to an inferior solution to the user with far higher memory and storage consumption.

source

Pkgsrc

this one is something in between Nix and traditional package managers. It’s main advantage is that it works in other UNIX-like OSs, like FreeBSD, NetBSD, IllumOS as well as in Linux. The only not Linux specific option in this list (other than docker, which is not a package manager but a container)

Docker

I wouldn’t recommend this one, since it requires packaging a whole OS that creates a lot of overhead. And it can be tricky to use with GUI programs.

Overall, I think that Nix/Guix present the most advantages, with Pkgsrc being a less known close second and Flatpak being in the third position due to it’s relative popularity and overall advantages over snaps and docker. Docker might be decent option if it’s a program designed for servers, tho.

I’d also recommend that you add your program to the AUR, because even if it only works on Arch and Arch based distros, it’s incredibly easy to do and maintain as long as the building of your program doesn’t change drastically between versions.

Edit: formatting

I’ve used nFPM to great affect.

Some native distro formats are unlikely to ever be supported by services of this type. For instance, neither of the two services you list in your opening post will generate Gentoo ebuilds, most likely because the process is fundamentally different: an ebuild is a set of instructions for the package manager, not a prepacked binary.

fpm is not a complete solution. It just creates a package from your files, however you need to build them in the environment of the distribution where it is supposed to work, with the same versions of dependencies. OBS is the best solution I know, but with it you need to write packaging scripts compatible with each distro you are targeting. It is quite time consuming and requires a good knowledge of native packaging tools.

You can also use any CI system that is able to execute builds in containers with your target distros. This requires a bit more scripting (just a bit), but modern CIs are easier to setup than OBS in case you need your own instance. This also allows you to use your favorite VCS and workflow you are comfortable with.

You don’t.

No, seriously. Let the distros package your software; they know how to do that best.

The normal way I believe is to provide dpkg, and rpm to cover a few distros and to make sure your software is good enough for someone to pick up and maintain packages for other/their distros. ;)

The options you already mentioned seems a good fit - with OBS being a bit rpm centric.

deleted by creator

deleted by creator