Hello Romain, others, On Thu 12 Aug 2021 at 02:06PM +02, Romain Porte wrote: > 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.). I understand your frustration and I appreciate you persevering with involvement in Debian -- thank you! I'd like to offer a brief counterpoint to some of what you say, however. In many cases, indeed, the reasons why things like dh are not in use is simply that no-one has taken the time to update the package yet, as you say. However, in other cases it is because the maintainer has thought through the options and decided against using those particular tools and workflows for principled reasons. For example, there are those of us who think that the downsides of the combination of 3.0 (quilt) and patches stored unapplied in git are significant, and so we have made attempts to provide alternatives, such as git-debrebase. Contributing to Debian would be a lot less fun if we were asked to just set these reasons aside and use something which to us is clearly technically inferior. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature