Maybe you want a non deb specific packager. cpack (cmake packager) can generate Windows, OSX, DEB, RPM and simple archives. There is also fpm that doesn't support Windows, but supports plenty of packet managers. And possibly many others.

AppImage, FlatPak and Snap may actually be worse in that regard, because they are like other distros you have to take into account. So now, you may have to do all of them: deb, rpm, flatpak, snap, appimage, tgz, whatever that's on Windows and OSX, maybe a Docker container too, app stores and mobile stuff, and upload to some npm, maven, crate.io,... It makes generic package manager even more important.

I'll check it out, thanks.

The dh tools have a lot of magic to them. Arguably it works rather well, but figuring out how exactly to build a package correctly is difficult. The documentation is pretty bad, so if you want to do anything slightly different than the standard, you going spelunking in the debian directory of existing packages.

Debian could fix a lot of the troubles with the existing Debian Helper tools by improving the documentation.

Preach! Creating custom debian packages is a path I hate to tread.

I have had good luck with fpm, which makes it easy to make packages of all different kinds, including deb and rpm: https://github.com/jordansissel/fpm

For me rpm was relatively easy to grasp, it's basically a shell script and each section has a specific job (building, preparing, copying files etc.)

No matter how much I tried I could never grasp deb packaging. The documentation is very sparse and the debhelper commands seem like magic. I couldn't find out what all the different files like .dirs or .install did, so I just gave up.

I find RPM specs to be pretty frustrating. Easy cases like packaging GNU Hello is fine, but things get out of control really fast once you fall off the happy path. RPM specs are based simple text substitution. It lacks the flexibility to make adjustments to the build, the power to build good abstractions, and comes with all the same drawbacks of the C preprocessor. On top of that, documentation is lacking for basic macros, language ecosystem support is spotty and scattered across various obscure projects, and SCL packaging is a complete nightmare. The whole design seems dated compared to other solutions.

Write a build script in your language of choice and then call it from RPM spec.

At that point, why even use package managers? That approach won't benefit from existing packaging infrastructure at all. Might as well distribute binaries in tarballs instead for simplicity.

Slackware uses tarballs, so use Slackware instead. :-/

> No wonder people are attracted to flatpak and snap.

And nix.

> Creating a installer for mac, windows and linux is a hell of a work

Nix gets you mac, linux and WSL support.

Will look into it.

https://nixos.org/download#download-nix <--- I'm bookmarking this cause I keep forgetting that Nix can run atop other systems. I have no excuse to not give it a try

This is a way improved[1] version of the official installer, capable of uninstallation among other things, there is no need to use the official one: https://determinate.systems/posts/determinate-nix-installer

1: https://github.com/DeterminateSystems/nix-installer?tab=read...

The easiest package format I've ever came across was the tgz format from Slackware. From what I remember, you just build and install your software in a fake root then tar gzip it up.

This is because it doesn't do very much. Arch Linux's PKGBUILD and Alpine's APKBUILD are an excellent improvement on that, still very simple to use and learn. In most cases the source package consists of a single shell script (unlike Debian's splintered hell) where you have to define half a dozen fields and a couple of functions (build && install).

I basically have to relearn Debian packaging from scratch every time I have to do that, but learn Alpine and/or Arch once and you're all set.

https://gitlab.archlinux.org/archlinux/packaging/packages/mu...

https://git.alpinelinux.org/aports/tree/community/mutt/APKBU...

It's the same process for all package builders: install build-time dependencies, unpack source archive with a program, configure it, build it, install it to a fake root, validate it, archive it to the package, sign it, then publish it to a repository, update repository index.

Binary deb packages are extremely simple. It's just a cpio archive with a couple of tarballs & almost every system integration is implicit. Very easy to build by hand.

Last time I shipped a debian package to clients we just had the build system spit out a ready made binary .deb. Much, much easier than faffing about with dhbuild etc.

I usually start with the `dh_make` generated skeleton and incrementally add overrides as I iterate with `gbp buildpackage`. It's not pretty, but it's what I know.

My work workflow use `dpkg-deb`: I just create a "build/DEBIAN" directory, populate it with the control file and any post/pre scripts I need, put everything else in the "build" directory where it goes on the end filesystem and then do "dpkg-deb build ." I put all this into a script and do "fakeroot <SCRIPTNAME>".

> I've had to build a deb package once. It's crazy how few docs and resources there are to do so, and how of poor quality they are.

After doing the first one, I was able to build binary, Debian packages in 5 minutes tops, while chatting with a friend during the process, too.

flatpak and snap are designed to solve different problems than OS native packaging paradigms.

Also, .deb and .rpm are much more capable and sophisticated than they look on the surface. Lastly, extracting a source and binary Debian package provides great documentation in itself.

Lastly, use lintian. That thing is a godsend (and does binary static analysis, too!).