Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16
Jonas Meurer <jonas@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: