In my experience, once you have a .deb package, it does indeed work perfectly. However, getting to that stage, unless you're packaging a collection of plain files with very simple dependencies, is the hard part.
Ignoring the weird scaffolding you need just to package a static "hello world" binary, there's also all the dh_ scripts which you should use for your package to be "well-made".
I remember looking up how to properly package a Python application, found like 5 different ways documented on the debian wiki, couldn't get any of them to work, gave up and just shipped a whole virtualenv.
This mirrors my experience, too. Building a simple RPM isn't too bad, even if spec files are a little arcane. Packaging for the AUR isn't super complicated as far as I've seen.
The "standard" way to build even the simplest deb file seems super overcomplicated whenever I've tried to do it, with layers of complexity, shims and fudges.
For most simple stuff you just want to specify a bit of metadata, a couple of install scripts and specify "X goes in /usr/bin/X, Y goes in /usr/share/...".
I tend to find that fpm (https://fpm.readthedocs.io/en/latest/) does that for me, and I now use it for building my own deb files pretty much everywhere.
Debian and Python purists will say otherwise, and there are some reasons not to do it - e.g. wanting to support multiple Python versions across multiple distributions (such as Debian, Ubuntu, and CentOS). But I agree, in my opinion it is the most reasonable way.
> However, getting to that stage, unless you're packaging a collection of plain files with very simple dependencies, is the hard part.
What do you mean plain files with simple dependencies? A deb file is just a zip that stores metadata and your artifacts exactly where you want then to be in the directory structure you see fit. You specify the packages you depend on in the meditada, zip them up, and that's it.
If you need something fancy you can add shell scripts that are triggered in parts of the installation lifecycle, but those are far from being mandatory.
Hell, if you prefer to follow the lazy way out you can even get build systems to generate your deb files for you. Cmake handles this out-of-the-box.
> Ignoring the weird scaffolding you need just to package a static "hello world" binary
What? That "weird scaffolding" you're referring to is literally the directory you zip with the artifacts in their destination and the metadata! Is it too weird for you to deploy libraries in /use/local/lib before you package them? What are you talking about? You build your static "hello world" binary, you place them in the destination folder, you fill in the metadata to specify dependencies and stuff like your name and email address, and you proceed to zip up the package. Done.
> (...) found like 5 different ways documented on the debian wiki
No you really didn't. At most you found references to 5 different tools that help you do the same exact thing.
Here's a link to a process you tried to described as undecryptable:
> You build your static "hello world" binary, you place them in the destination folder, you fill in the metadata to specify dependencies and stuff like your name and email address, and you proceed to zip up the package.
this small "fill in the metadata" part is already half-an-afternoon of reading and understanding all the concepts and mandatory files in there: https://www.debian.org/doc/manuals/maint-guide/dreq.en.html ... and that's only one small part of the manual.
Arch packages in comparison can be a single 15-20 lines PKGBUILD shell script.
The scaffolding I'm referring to is the "debian" directory containing rules, controls etc..
The built-in Debian packaging tools are already wrappers on top of wrappers on top of wrappers, adding another layer on top of that (with Cmake or whatever) only adds to the confusion and goes to show how over-complicated it is.
For example, the article you linked uses dpkg-deb --build while I've seen alternatives use dpkg-buildpackage and debuild.
The 5 different documented ways was specifically referring to Python packages.
There are also helpers like dh_systemd which I could never get to work so just ran systemctl commands in postinst and such.
Ignoring the weird scaffolding you need just to package a static "hello world" binary, there's also all the dh_ scripts which you should use for your package to be "well-made".
I remember looking up how to properly package a Python application, found like 5 different ways documented on the debian wiki, couldn't get any of them to work, gave up and just shipped a whole virtualenv.