Re: Proposed release goal: fix debian/rules build-arch
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.
Reply to: