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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
