[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Buildd & binary-indep



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?

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.

And yes, "one line" is added complexity. It makes it that much harder to
learn how the debian source format works.

> The only reason to not make them required directly is that it would make
> the largest part of the archive instantly RC buggy. Thus the suggestion
> is that there is a way to introduce new policy rules without upholding
> them to old packages, thus by saying a specific bug is only RC (or a bug
> at all) if Standards-Version says this package was made looking at the
> new rules.
> 
> Making the field then operational is a rather different part (though
> still much easier than all the other heuristic approaches), but even
> without that I'd guess we could reach a working state in a much shorter
> time (people get those lintian warnings about no having current standard
> version, if they upgrade it they must also add that line if their build
> system does not support it...)

This smells the same as the /usr/share/doc transition. That took 
*years* -- and without significant efforts, it would have never finished.
We need to learn from that mistake. In the /usr/share/doc transition we
glommed onto a particular archive-wide change without considering that
spending a few months fixing dpkg could completely have avoided it. We
already know of multiple ways to support split building without
modifying every source package, so there's really no justification to
propose changes that impact the entire archive.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature


Reply to: