Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote:
> On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote:
> > Someone else already had this idea:
> >
> > https://people.debian.org/~stapelberg//2016/11/25/build-tools.html
>
> Excellent, this is a great start, and seeing "Michael Stapelberg" for me is an
> indication of quality.
You say that, but this is incredibly biased. Even he admits that in the
colour choice. Disclaimer: as the cowbuilder maintainer (which comes
from the cow*dancer* source package, for historical reasons, despite
what the diagram may tell you) I am of course also biased. But I notice
that for the sbuild path, schroot is completely missing, which is
implemented in C++ and therefore probably deserves a bright red colour
just like cowbuilder in his second picture (or maybe even something
worse, depending on your views of C++). Then there's the extremely
unhelfpul, hostile comment at the end:
> I propose to eliminate complexity in Debian by deprecating the
> pbuilder toolchain in favor of sbuild.
Now, I am not necessarily against simplifying workflows, but choosing
one to rule the all arbitrarily because you prefer the language it's
written in is not the way to go about it. There are also benefits to
having a variety of implementations; they behave slightly differently,
sometimes not implementing policy in the same way, and this can be a
good thing, allowing policy to be clarified, or finding mistakes in the
other builder, or just exposing flaws in your package. For example,
pbuilder will by default use a new isolated network namespace for the
build, whereas sbuild won't, so if you just use sbuild you may not be
aware of violating policy (4.9). I'm not trying to sell pbuilder over
sbuild here though; there are also many ways in which sbuild is better
than pbuilder.
James
Reply to: