On Mon, Feb 16, 2009 at 11:21:42AM -0800, Russ Allbery wrote: > Such a requirement unfortunately still won't mean that Lintian can use > that option to do a check of debian/rules. As long as make is willing to > run such code, we can't just rely on a Policy statement saying that you're > not supposed to do that. It is, among other things, a security problem.
That's a good point, but not running debian/rules means that you'd be making it a requirement to write debian/rules files in a stylised way, to make it greppable. Conventions are one thing, that'd be another. That'd have a human cost too. But this is somewhat coincidental to this. Coming up with a test, even an imperfect one, could help push changes forwards. > I have to admit that I'm tempted by this approach, mostly because it's not > clear to me that the build-arch vs. build-indep separation actually gains > us anything that useful. The point, so far as I can tell, is to save > buildd time by not building the architecture-independent packages. How > much time would we actually be saving? Is it worth putting a lot of human Ask buildd admins. They could start downloading and installing B-D-I along with B-D today. Deprecating B-D-I and -arch and -indep would be a small step after that. > effort into making that situation possible? Generally CPU cycles are far, > far cheaper than human cycles. Another thing that B-D-I is good for: breaking dependency cycles. An example from the upcoming version of ghc6: ghc6 uses haddock to build API docs. Haddock needs to be built with the same version of ghc6 it generates docs for. Putting haddock in ghc6's B-D-I avoids that cycle. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
