On Mon, May 22, 2017 at 05:10:26PM +0100, Jonathan Dowland wrote:
> On Mon, May 22, 2017 at 03:25:38PM +0100, James Clarke wrote:
> > On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote:
> > > Excellent, this is a great start, and seeing "Michael Stapelberg" for me
> > > is an
> ^^^^^^^^^^^
> > > indication of quality.
>
> emphasis on *start*
To qualify as "great" I think you should be accurate, but hey, maybe I
have too high standards. Anyway the main point wasn't to attack you but
to provide another side to that blog post.
> > You say that, but this is incredibly biased. Even he admits that in the
> > colour choice.
>
> I was completely ignoring the colour choices and implementation language.
>
> > that for the sbuild path, schroot is completely missing
>
> Indeed there are a lot of omissions. I think the next step, whether this
> is the basis for what goes next, or not, would be to get the source of
> this picture (or another) into a version control system so it can be
> iteratively and collaboratively improved.
That sounds sensible (for the uncoloured version).
> [ Stapelberg via James Clarke ]
> > > 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.
>
> Language should be a factor, as there are practical considerations that can't
> be avoided, independent of personal preferences – but I got the impression
> that he was not coming to this conclusion soley on the basis of implementation
> language anyway, nor soley in terms of his own preferences for implementation
> language.
Sure, language can be important, but I would say Bash and C are *more*
accessible to the average developer these days than Perl, and that's
only going to become more true over time. He didn't give any other
reasons, but if there are, these would be welcome in the form of
constructive bug reports so we can address them and make the situation
better for everyone.
> > 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.
>
> These are good points. However, considering just these points in isolation,
> the "secondary" implementation(s) would not need to be something that was
> actually geared towards real users, or advertised as such.
There already effectively is a semi-"primary" implementation given that
sbuild is used on the buildds. And as for making these "secondary"
implementations not geared for real users, for whom would they then be?
Designating a certain tool as "primary" will just lead its behaviour
becoming the de facto policy, so everyone will be required to build with
it locally, and so nobody would even consider using a secondary
alternative.
> > I'm not trying to sell pbuilder over sbuild here though; there are also many
> > ways in which sbuild is better than pbuilder.
>
> I am not (yet) familiar enough with either of them (or the other dozen or so
> similar tools for the same job) to come to a conclusion on what I think would
> be the correct number/recommendations for Debian contributors, but I am of the
> initial opinion that there are too many. I've heard a lot of good things about
> sbuild.
There are lots of areas where Debian has far too many tools to
accomplish the same thing, but I don't think this is one of them; there
are only two main tools for building in chroots (sbuild and
pbuilder[0]), both of which have significant user bases.
Anyway, I'm done with this debate; it's clear I have very different
views from some on this matter.
James
[0] cowbuilder is a thin wrapper that behaves (almost) identically, so
it doesn't really count as something different
