Re: Proposed release goal: fix debian/rules build-arch
Kari Pahula <kaol@debian.org> writes:
> 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.
No, buildds do not install B-D-I contrary to what policy says they
must. Which is part of the problem the proposal wants to fix.
It also isn't so much the building itself, most arch-indep stuff
builds pretty quick. The bigger saving is not having to download,
unpack, configure and remove all the B-D-I packages. Installing for
example latex and updating the font cache takes forever. And you have
to do that for every single package with tex docs again and again and
again.
>> 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.
Any such cycle would result in all its packages being stuck in
dep-wait forever if buildds would follow the current policy and
install B-D-I.
MfG
Goswin
Reply to: