I made my own custom packages for Alpine Linux and Arch Linux for personal use. It is so easy that I am honestly I'm not seeing the point in doing things the way Debian does it. It just makes things unnecessarily difficult for no reason.
What does a maintainer realistically do?
He builds the software, so you expect that the package builder automatically installs the development dependencies and runs the build software inside a chroot.
In case the software requires modifications, there needs to be a way to deliver patch files or additional files that aren't part of the original software or at least a standard location to store the distro specific fork that everyone agrees on.
Once the software is built, the maintainer creates a directory structure that conforms to the distributions's conventions, adds things like systemd unit files or desktop shortcuts and other distro specific changes that exist outside the software.
I would encourage everyone to at least give Alpine or Arch Linux packaging a try. It really is quite easy. Almost as easy as writing a docker file.
Debian maintainers have to coax upstream packages to behave like other Debian packages and use supported linked dependencies. This covers everything from log and config file locations, startup scripts patching dependencies to match the versions supported by the release, backporting security updates, and documenting.
I trust Debian (and in turn Debian maintainers) more than I trust the upstream developer of lib-random-4-dev. I only ever had to build a custom package from source a handful of times.
Simpler packaging formats like pkgbuild and apkbuild do all of that too. They're easier to use because they do away with "convenient" automation that makes simple things trivial, and slightly more complex things very difficult. You just use the shell with all the standard commands.
I agree and add Void Linux to the list in the same vein.
Generalley, ports-like package repos (all package build recipes in one repo) are really beneficial for large-scale operations or simply rollbacks.
Being able to bootstrap the distro from a git repo and a well-defined set of bootstrap tools is really nice. try that with debian.
See Void Linux and Alpine for a simple, yet refreshing aproach to distro package maintenance, with low overhead.
It's easier because you get a sane shell instead of a poor reimplementation of a tiny subset of one.
I maintain many aur packages, and wrote the first one in half an hour, knowing nothing about Arch packaging at the time. Now it takes me maybe 5-10 minutes to package a small application that adheres to the standard conventions.
I spent maybe two days on my first Debian package. It was also the last one (not really, but almost so).
What does a maintainer realistically do?
He builds the software, so you expect that the package builder automatically installs the development dependencies and runs the build software inside a chroot.
In case the software requires modifications, there needs to be a way to deliver patch files or additional files that aren't part of the original software or at least a standard location to store the distro specific fork that everyone agrees on.
Once the software is built, the maintainer creates a directory structure that conforms to the distributions's conventions, adds things like systemd unit files or desktop shortcuts and other distro specific changes that exist outside the software.
I would encourage everyone to at least give Alpine or Arch Linux packaging a try. It really is quite easy. Almost as easy as writing a docker file.