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

Re: Request for TC to rule on a course of action for supporting build-arch

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> (Sorry to just join this conversation; I was on holiday in Wales,
> which was excellent.)

> Raphael Hertzog writes:

>> I was going to suggest that. The way I prepared the corresponding patch
>> (the one you called "auto-detection") already does that in fact. So the
>> few packages were the auto-detection does not work would add
>> Build-Features in the mean time and the make -qn call will be entirely
>> skipped.

> This is a good suggestion.

> Personally I don't see why Build-Options isn't sufficient, as a
> temporary solution, once we realise that only the packages for which
> we actually care that the buildds use build-arch need to declare the
> Build-Option.

I think Build-Options is a poor temporary solution because it adds
artifacts in debian/control that we then want to go away again.  It's
something we can use if we want to leave this facility around forever, but
I don't think that's our goal.  Our goal, rather, is to make build-arch
mandatory in the long run.  So Build-Options essentially works directly
against the goal here.

> Ie something like the following plan:

>   wheezy: everyone SHOULD implement build-arch
>           If package takes a long time to build, SHOULD advertise
>            in Build-Options; otherwise MAY

>   wheezy+1: MUST implement build-arch; MAY advertise in Build-Options

> Personally I think the make -qn test is a horrible hack and I'd prefer
> any solution which avoided it.  But if we must have it, then Roger's
> suggestion to do it only if not advertised in Build-Options is sensible.

> NB that although for this particular case, Build-Options seems overkill
> (since you can usually very easily provide the feature) I think it's a
> useful precedent for other possible features.

That's been the argument for some time, but people have great difficulty
coming up with another feature for which that would be the right solution.
Usually the problems that seem to point towards that solution are
better-solved through some other method, such as a helper in debian/rules.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: