KAkasabali·Sep 26, 2024Recommendation phrase
I agree completely. On the other hand, it should be recognized there's a difference between packaging for the official repository and packaging done by individual users/sysadmins/developers for distributing independently. Unfortunately all of Debian's tooling and documentation is for the first scenario.
I must emphasize, I'm not saying, to quote you, that the documentation should more accessible, but nobody has stepped up to do yet. I'm saying, they're completely fixated in their approach to tailor packaging tools and documentation for creating packages for inclusion in official repository. Debian's tools and documentation for creating ".deb" packages are completely intermingled with their policies for including packages in the official repository. That's where all the complexity comes from. They're mixing the policy (Debian repository r
Read the rest
ules) and mechanism (deb format), and unless they recognize this, no amount of packaging tools or documentation improvements will solve it.
Which is such a shame by the way, because like you said, Debian packaging ecosystem is really powerful and would render a lot of complex machinery devops people use today unnecessary. You can distribute out-of-band updates to data files, push configuration (instead of configuration management) [1], do deployments with virtualenv/gems included (instead of containers) [2], proxy/partial repo mirrors for staged updates/deployments etc. Unfortunately if you decide to it, you'll either have to go with the Debian sanctioned way and tear your hairs because of unnecessary complexity, or you'll go look for 3rd party tools and hunt for blogs posts all over the internet as substitute documentation.
[1] https://wiki.debian.org/ConfigPackages
[2] I recommend checking out Vincent Bernat's excellent "Pragmatic Debian Packaging" series (https://github.com/vincentbernat/pragmatic-debian-packages) for some examples