Re: Buildd & binary-indep
* Joey Hess <joeyh@debian.org> [100929 18:33]:
> Bernhard R. Link wrote:
> > There really is no reason to keep build-arch and build-indep optional
> > (the only reason would have been to allow for them becoming widespread
> > on their own and then requiring them once that has no big effect), as
> > every package not supporting them can support them by a single line in
> > debian/rules: "build-arch build-indep: build".
>
> I hope you're not seriously suggesting we need to modify every single
> source package?
I'm more than serious with that. It's easy, doable and the only sane
solution.
> Very very few packages are ever going to need a split build. Pushing
> complexity off onto every other package to enable that is bad design.
I beg to disagree massively. We already have binary-arch and
binary-indep in every package. Having a clear interface ("you have to
have build-arch and build-indep") is in my eyes the least complex
solution possible.
Any wild guessing whether a package supports it or not has not only
had shown suprising failures in the past, but makes things only less
predictable (which is the worst result of complexity).
Any additional decriptive language which describes how to use the primary
interface does not really says "good design" but "design for design not
for functionality" (especially has those additional data brings no
redundancy and no easy way to catch errors like supporting build-arch
and not advertising it, and advertising it without supporting it will
also only be found with the first -B call).
> And yes, "one line" is added complexity. It makes it that much harder to
> learn how the debian source format works.
Now I really have to ask if you are serious.
How is having binary-arch, binary-indep and binary called by one set of
rules and having an optional build-arch, build-indep called by other
rules and having some additional meta information filled out any more easy
to learn then just requsting to have both and them being called by the
same rules?
> This smells the same as the /usr/share/doc transition. That took
> *years* -- and without significant efforts, it would have never finished.
Sorry. Even if that was comparable and thus true, it still means that this
is by far the superior solution. Only taking years means it has a
result and we would have got a useable build-arch by now multiple times.
All those "we need some way to decide if a package supports that and if
there is no way to do that we need a way of the source package that
universally describe build features including if we have that rules or
not" has now failed for about a decade. And I see no reason why this
approach should not fail for another decade, and the decade after this.
> We need to learn from that mistake.
I hope we will learn something from the failure of build-arch, too.
Bikeshedding and overengineering can be an serious harm.
> We
> already know of multiple ways to support split building without
> modifying every source package,
First of all, it's by far not every source package. Everything using
some automagic stuff has no excuse for not supporting them. Everything
doing things more explicitly can just add a little expliciticity here,
and there are enough source packages not needing a split still
supporting it (all of mine, for example).
And more importantly, I fail to see how something can be called a
solution if it does not solve the problem by simply being stuck.
Bernhard R. Link
Reply to: