In contrast, with Gentoo and their documentation, it was straightforward for me to make my own additional, separate repo, look at other ebuilds to see how packaging works, and have everything just work.
https://github.com/billsix/billsix-portage
I submit ebuilds to Gentoo itself if I think others would benefit.
As far as I can tell, packaging for Arch is straightforward as well.
It won't pass all lintian tests due to the ridiculous requirements and useless ceremony "correct" Debian packages need. Still working on it.
As it turns out, it doesn't take that much effort to make packages that comply with Fedora/openSUSE Packaging Guidelines and Debian Policy with this tool, and it has drastically simplified my ability to maintain software across distributions in a way that still cleanly integrates with the distribution platform.
This is how the Spacewalk Debian/Ubuntu client packages are built[3][4], among many other things. There's also a few other examples out in the wild[5][6][7].
At least for the stuff I make for myself, I haven't made packages that fully pass lintian, but it's not terribly difficult to do if you want to.
[1]: https://github.com/ascherer/debbuild
[2]: https://openbuildservice.org/
[3]: https://gitlab.com/datto/engineering/spacewalk-debian-client...
[4]: https://build.opensuse.org/project/show/systemsmanagement:sp...
[5]: https://pagure.io/python36-flatpkg-deb
[6]: https://pagure.io/rpmdevtools-deb
[7]: https://build.opensuse.org/package/view_file/Virtualization:...
https://github.com/kakwa/amkecpak
It doesn't exactly simplify the Debian packaging in my case as it leaves the packaging mostly exposed.
But it provides a lot of far more convenient and easy to remember commands (make rpm, make deb, make deb_repo, make rpm_repo, etc) compared to the easy to forget options of rpmbuild/mock and dpkg-buildpackage/cowbuilder.
It also glues everything together from upstream source recovery to building the final repository ready to be rsynced on a public server.
It's a monorepo, and packages are declarative. So for most usecases, its just 5-10 LOC describing the source location, dependencies and build process.
After that, if it builds on your local copy of Nixpkgs, it will build on the same Nixpkgs commit as everything is purely functional. A simple PR is all you need.
For updates, there's super low burden too. Thanks to packages being declarative, everything is quite explicit. So a bot can check for source updates upstream, update your package and rebuild it. All it requires is simple maintainer approval.
[1]: https://github.com/NixOS/nixpkgs/blob/fce8f26af6ef8209c7d282...
https://linuxconfig.org/easy-way-to-create-a-debian-package-...
And then a quality of life enhancement says push the package building off to FPM.
https://github.com/jordansissel/fpm
Personal Repo
https://www.digitalocean.com/community/tutorials/how-to-use-...
This is the root of the Debian newbie community experience. FPM seems to get it at least.