Hi, 11/08/2021 16:08, Vincent Bernat : > I think we have more systemic issues. I am quite impressed how Nix/NixOS > is able to pull so many packages and modules with so few people. But > they use only one workflow, one way to package, one init system, etc. > Looking at Arch, one workflow, one way to package, one init system, etc. > Looking at Fedora, one workflow, one way to package, one init system.
I think this is a major point. I am a new Debian contributor after a good time of ArchLinux PKGBUILD writing. I find Debian technically superior on the packaging side, and would not trade it for PKGBUILD. But there are so many ways to do things. After a lot of exploration, I have found that the tooling that I was the most comfortable with was: * Salsa VCS * GBP for git + patching (+ DEP-conformant branch names) * dh However there are so many other ways to do things. Some packages are not on Salsa. Some packages use manually generated diff files. Different branch names everywhere (debian/latest vs. debian/master vs. debian/unstable vs. master…). I think progressive enforcing of a workflow would help new maintainers to not be lost in the packaging jungle. > I still trust Debian to be the most technically excellent distribution, > but that's not all it makes to stay relevant. My point is that it would > help to reduce the technical liberties we take in Debian. However, I > don't think that's who we are. Maintainers like their freedoms, but enforcing some tools at some point could make it easier for everyone to contribute and not relearn the packaging process for every package, because currently every package is different. We are getting there by looking at the number of "3.0 (quilt)" packages and "dh" usage, but when a package does not conform to this norm, it triggers a mental freeze on my side (and I want to migrate it all to dh/3.0 quilt etc.). > Let me take again the example with Nix. Anyone can do a simple pull > request and gets its change accepted. Each package has a maintainer, but > the ownership is quite weak. The maintainer may say no, but if they are > just busy, someone else may merge the change if it looks reasonable. Maybe the interface helps too. With a single repository, everyone can see every pull request easily. For Debian you would have to monitor all repositories/bugs for NMUs waiting. > In Debian, we have many workflow (BTS, MR to submit changes, Git, not > Git, Git workflow 1, Git workflow 2, Git workflow 3), many ways to > package (just one makefile, old debhelper, new dh), many init systems. > And the ownership problem prevents people to help from time to time. > There are so many packages I come accross that could just be updated to > a more recent version and looks like semi-abandoned but I just don't try > any more because there are so many ways to fail. To me the problem is not to do the technical migration, but to make it acceptable to the current maintainer that will usually not want to change their workflow — or not answer at all. One issue is that you cannot repack everything and propose a NMU, because it is a major change. So what do? Apart from RFS or co-maintaining, I do not know how I can help "modernize" these packages. If I propose it as a .patch in a bug and it is refused because the maintainers "does not like 3.0 (quilt)", I have lost a good chunk of time. > Today, it is very difficult to only use Debian own packages. We just > tell people "just add random repositories". Nix and Arch are able to > have almost everything packaged. Nix is able to include into a single > workflow most other language ecosystems. We could have the same in Debian, but the constraints of "build from source" and lack of interest for "contrib" and "non-free" channels is in my opinion severely limiting the number of available packages. AUR contains many packages that are not open-source nor built from source, but users are happily using them when they want to. For example for Spotify or VS Code (or many other external, sometimes proprietary tools) you need to add an external repository. While on Arch I guess you would use AUR. Why could not we use "contrib"/"non-free" for the same purpose? In the fonts team, it is increasingly complicated to build fonts from source because they use so many javascript dependencies. I could propose to ship the final .ttf/otf fonts into "contrib" instead. But given the review duration for getting into "main", I guess "contrib" and "non-free" are worse in terms of given attention. Looking forward to pursue the discussion. Best regards, Romain.
