Re: draft ballot: please rule on how to implement debian/rules build-arch
Hi!
On Thu, 2012-01-12 at 16:47:18 +0000, Roger Leigh wrote:
> On Thu, Jan 12, 2012 at 05:27:40PM +0100, Raphael Hertzog wrote:
> > On Thu, 12 Jan 2012, Roger Leigh wrote:
> > > At this point, we have one working and well tested solution.
> >
> > Which one are you referring to ?
>
> I'm referring to using "make -qn" (with or without the additional
> presence of the Build-Options field). Either would do the job, and
> Build-Options would cater for packages where the autodetection breaks
> the build. Given the tiny number of packages affected, this isn't a
> big deal IMO.
I think Raphaël thought you were talking exclusively about a
Build-Options based solution.
> > > Is there any point in waiting on the TC at this point given that it's
> > > really the only sensible choice (as in, it's been tested on the whole
> > > archive and we know its impact is very low, and we don't have any
> > > alternative patches at this point which offer a better solution).
> >
> > IIRC, the solution that you're referring to is one that Guillem was not
> > really pleased with. So that makes a reason for a TC ruling.
>
> OK. Guillem (CC'd), are there any existing viable alternatives to
> "make -qn" (with or without Build-Options) which you are happy with?
> Note that the purpose of this change is not a "perfect" long-term
> solution, but a "good enough" solution which will permit the adoption
> of build-arch and build-indep without a flag day which would break
> everything. It can be removed once wheezy is released, following
> which the targets can be made mandatory. Of course, if a better
> method of target autodetection is found in the interim, we can
> adopt that instead. This would strictly be to enable the
> transition.
I think I've stated my take on this at least in #604397. In any case
I'm fine with mostly any solution ranging (in no particular order)
from a global activation of the targets on a flag day to incremental
activation depending on the Build-Depends(-Indep) fields, to
autodetection heuristics, or combinations of those, as long as any
such temporary hack is confined to dpkg itself. But certainly I'm not
fine with a Build-Options/Build-Features kind of field solution that
percolates into packages, when they should just be fixed to support
build-arch/build-indep.
> As I see it, we've been waiting for such a perfect solution for over
> eight years, and because of that, it's never happened. A less-than-
> perfect solution would have allowed this to be done years ago. We
> need it working for wheezy, and in the absence of a better solution
> having your consent to go with the "make -qn" solution would at
> least allow some progress to be made. It would only need to be
> there until the release of wheezy.
IMO the main problem here has been not using these eight years to just
start deploying build-arch/build-indep into packages independent on how
or when dpkg was going to start using them, a lintian warning back then
would have made wonders and by now the archive would be mostly covered.
In any case I don't think I've ever opposed «make -qn», all the
contrary!
thanks,
guillem
Reply to: