[debiandev]

> weird poorly-documented helper scripts which have strange interactions

I've never found a packaging tool without an extensive and clear manpage with examples.

> I think the biggest issue is the social problem of the long and arduous process to become a trusted Debian Developer. Although there's now an easier Debian Maintainer option for restricted access, it's still not easy to become one. Other people have to go through a developer to update or add packages.

There is an arduous process to become a senior engineer in a FAANG, or a tenured professor, or an airline pilot.

That's why a lot of people trust Debian.

[bhaak]

> I've never found a packaging tool without an extensive and clear manpage with examples.

That might be fine if you already know which packaging tool to start with. Debian has several and it's not clear upfront which one is the preferred one. But even then I'd say that there is something like too much information.

And the process is complex. If I want to package a standard autoconf/cmake program, I have to do a lot of command typing. If you compare that to Gentoo, Arch or even Homebrew packages where you essentially edit one file and one or two command invocations, that's just cumbersome.

I recently tried to find out what I would have to do to for a NMU and I just couldn't find any entrance point that made sense to me. It felt like trying to get into a cabal and all the information is encoded in arcane Latin.

[jelmer]

The process is indeed complex, but there are efforts to standardize on a single simple way to do packaging. Unfortunately with an archive of 30k source packages, that is a slow process.

A great resource is https://trends.debian.net/, which tracks some of the different ways of doing packaging, as well as the progress on convergence.

With the new style debhelper that we're converging on and a straightforward package, creating a new package should not have to involve a lot of typing - although it's still split across multiple files.