user debian-pol...@packages.debian.org usertags 604397 + normative discussion quit
(please consider dropping policy Bug#604397 or dpkg-buildpackage Bug#229357 from replies) Hi, Roger Leigh wrote: [out of order for convenience] > Just for the record, I've implemented support in debhelper's dh > command in #604563. Once applied, this will automatically add support > to the huge chunk of the archive using "tiny" rules files. cdbs will > be next on my list. debhelper 8.1.0 has such support now. Thanks! >> * Roger Leigh <rle...@debian.org>, 2010-11-21, 21:38: >>> I'd like to propose that build-arch and build-indep be changed in >>> Policy from "may be provided" to "must be provided" in preparation >>> for enabling their use. Personally, I'm all for it; ideally it would happen in the following order: 1. Providing build-arch and build-indep becomes a best practice. lintian gains a check. devref encourages the practice. 2. Becomes a policy "should". 3. Becomes a policy "must". That sounds slow, no? Yes, that's the point. I'd like to propose that we not make most of the packages in the archive instantly RC buggy, today. >>> We've wanted to fix the root problem for >>> at least half a decade, and I'd like to get it done for wheezy. I just noticed this gem in policy ยง4.9: If one or both of the targets build-arch and build-indep are not provided, then invoking debian/rules with one of the not-provided targets as arguments should produce a exit status code of 2. Usually this is provided automatically by make if the target is missing. So it seems to me that "dpkg-buildpackage -B" ought to be taught to run the equivalent of debian/rules build-arch if test "$?" = 2 then debian/rules build fi . In http://bugs.debian.org/72335 the only argument against that I see is (and notwithstanding that we're going to require both or neither), it should say that "debian/rules -q with one of the not-provided targets ...", because the programs which will want to test this are likely to do something cheap like: debian/rules -q build-arch if [ $? -eq 2 ]; then debian/rules build else debian/rules build-arch fi To try a full build only to receive an exit status of 2 would not say whether the build failed or the target was not found. That doesn't seem so compelling to me; in the failure case, the autobuilder would just try to pick up where it left off and fail again, which doesn't sound so expensive. What am I missing? Thanks for moving this forward. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org