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

Re: build, build-arch and build-indep targets in debian/rules

Bill Allombert <allomber@math.u-bordeaux.fr> writes:

> On Mon, Aug 09, 2004 at 11:22:35AM +0200, Wouter Verhelst wrote:
>> [Why is this on -devel? Has nothing to do there. M-f-t set]
>> On Mon, Aug 09, 2004 at 07:22:14AM +0200, Goswin von Brederlow wrote:
>> > Hi,
>> > 
>> > in short (full rephrase below) I propose the following change to
>> > debian-policy:
>> Please read <http://bugs.debian.org/218893>, which was a previous
>> proposal to address this issue, instead of coming up with one of
>> yourself, out of the blue.
> FWIW, my plan about #218893 is to issue another proposal in November,
> which will change policy to implement what the buildd are doing, instead
> of changing policy so that buildd can implement policy 
> (basically adding the requirement that having a Build-Depends-Indep
> control field imply support the build-arch target.)

What if you don't need any Build-Depends-Indep but still waste 666h in
the build target for indep stuff? The Build-Depends-Indep is not a
sure sign of when build-arch is present or of when it is usefull/vital
to be used.

Also since, if I read the release goals correctly, Build-Depends (and
-Indep then too) are now a MUST directive linking the build-arch
target to Build-Depends-Indep makes the build-arch target sort of
mandatory (except those corner cases above).

Making the two targets always required seems simpler imho since then
we get all cases.

> I would like to mention that:
> 1) Writing such proposal correctly is some work.
> 2) We are busy releasing so discussing that now seems a distraction, and
>    policy is frozen anyway,
> 3) The common position of dpkg maintainers is not clear.
> 4) The fact that I issue a new proposal should not be taken as 
>    implying I prefer the new one over the (great) old ones.
> Cheers,

Point taken. But don't forget there is always something looming ahead
demanding our time. After the release there is a gcc transition coming
up and multiarch. Actually esspecially multiarch since that will
greatly increase the amount of -all packages.


Reply to: