Hacker News Reader

> 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.

To be fair, with the impact you could have in a role like this, with millions (billions?) of Debian or Debian-based devices and installations depending on it, worldwide...

It IMO makes sense that you only grant access once competence, non-malicious intentions and your willingness to stick around is established.

> 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.

> 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.

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.

The janitor is trying to help make packaging less toilsome:

- The janitor is trying to automatically migrate people to newer versions of debhelper, reducing the number of different build system variants.

- The janitor attempts to perform validation of all the long, complex, changing rules for you, so if you meet their requirements then it will propose an upgrade. If the janitor can automatically bring you into compliance with the rules, it will, otherwise it'll leave you upgraded to the step that requires a human to intervene. You can manually upgrade it one step, and then the janitor will loop back around and do the rest for you.

- The janitor will also fix suboptimal, or unnecessary packaging changes and improve them for you too, hopefully leaving you with a much smaller, simpler packaging system that's easier to reason about.

If a process doesn't work, adding lots of people to it will not help.

A major part of the problem is scalability. "In the old days" the automated system that eats signed binary packages and outputs a usable apt-get accessible archive, couldn't do much to any individual package if we wanted it to complete in time. Times change and people seem to want more testing and automation, toss the binary packages and rebuild all archs from scratch, more automated tests, etc.

In the long run you're basically asking why the archive automation scripts accept incoming packages with "debian-changelog-has-wrong-day-of-week" instead of kicking those package updates back. Adding more people isn't going to fix it, adding a large system working around the process is kinda helpful, but really the archive automation scripts should just not accept packages with "trailing-whitespace" any more than they'd accept packages with invalid GPG signatures. This will result in more processing time for updates, but this can be clouded and parallelized and is fixable in 2020, even if simpler archive processing made engineering sense in 1995.

> You also have the long, complex and constantly changing list of rules which need to be applied for each update. They are very strict about noting down the copyright of all the files, for example (which I can understand to some extent).

Tracking licensing information very strictly makes sense.

Other than that, however, the Debian packaging process is something only a lawyer could love.