Jonas Meurer <jo...@freesources.org> writes: > Depending on the software you packages, doing the initial packaging > already requires a lot of knowledge about library handling, doc build > systems, makefiles, the filesystem hierarchy standard, language-specific > toolchains, etc.
> To properly build the package you have to learn either sbuild or > pbuilder. Which involves understanding and creating chroots/VMs/... > For proper version controlling, things like git-buildpackage (and/or > dgit) and the "3.0 (quilt)" format need to be understood. > And for testing, you need to learn about piuparts, autopkgtest, as well > as again chroots and/or containers for local testing. > That's a very high bar for entering the world of Debian packaging. I completely agree. How can we fix this? I've written some documentation of my personal approaches, but I think documentation, even with step-by-step instructions, may not be the best way to cut through all that complexity. When I look at other ecosystems, there often is less diversity than we have in Debian (newer languages like Rust or Go, for instance, have converged strongly on a single choice of build system), but perhaps even more helpfully they've automated a lot of that flow or at least wrapped it into single tools. Debian rightfully values its diversity, and while I think pushing us to think about whether that diversity is still serving a purpose is valuable, I am sure we don't want to give it up entirely. But I think there's a missing gap here for a very opinionated combination of a tool and a document that says "here is one coherent way to package things for Debian; you don't have to do things this way at all, but if you don't have opinions about all this stuff, use this." I don't think we have that right now. By this, I mean way more than just the packaging. Imagine a world where you apt-get install decisive (name made up) and then run decisive setup and it sets up an sbuild environment for you, and then run decisive init on an upstream directory and it builds a packaging template using dh and 3.0 (quilt) and autogenerates your copyright file using licensecheck. Running decisive format runs cme fix, running decisive lint runs lintian and cme check, running decisive check runs puiparts for you, and autopkgtest, and whatever else we can come up with. Running decisive upload runs dgit push for you. And so forth. We have some of those pieces already, of course, and writing this sort of tool is a little fraught for all the tools upstream of them since they'll get an influx of user bugs from people who don't really understand how the tool works because they're not using it directly. So this isn't without cost. But I don't think we've ever assembled the *entire* packaging workflow into a tool like this that has strong opinions and a mandate to *not* allow every possible variation and instead just focus on being a very simple and easy-to-understand workflow for the 80% case. (Obviously we'd want to try to design it so that it's relatively easy to use selectively as someone gets better at packaging and makes some alternate choices.) To be clear, I personally don't have time to work on this. But I think it would fill a valuable niche in our ecosystem, particularly if accompanied by a supporting document that lays out *why* those tools were chosen and provides a few pointers to alternatives for someone who starts getting curious about other ways to do things. I've seen this kind of approach be successful elsewhere; the idea is to make common things easy while getting out of your way if you need to do something uncommon and complicated. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>