gen-build-deps only reflects one level of depth

[jdreed]

In attempting to build for oneiric, we ran into a couple of failures:

• cupsys-config build-deps on cupsys-hack, but nothing provides cupsys-hack, so it doesn't get listed in deps.mk and cupsys-config lacks build-deps. We "fixed" this by removing cupsys-hack since it's no longer needed.
• athinfod-cluster-config build-deps athinfod, which deps machtype, but again, this was not reflected in deps.mk, so athinfod-cluster-config couldn't build. I see no where in gen-build-deps where this relationship could possible be described

Do we know for sure that this ever actually worked correctly? Or were our dependencies so simple before we never noticed that this has always been broken?

[jdreed]

OK, I think cupsys-hack was a fluke, but athinfod-cluster-config is interesting. Nowhere in gen-build-deps do we address the case where Package foo build-deps on bar, and bar in turn deps on baz. So bar will correctly get built before foo. But when bar goes to be installed, baz doesn't exist, so install fails.

The other case that's not represented (I think) is if Package foo-client has a Source of package foo, and something build-deps on foo-client, foo won't necessarily get built in the right order unless it also Provides something.

Now, this eventually works the more you retry things, but that kind of sucks, and for new developers, it might not be immediately obvious why a package failed.

So we need to find a way to represent this relationship. I suspect the right thing to do here is: if a package's build-dep is itself a debathena package, that package's deps to the original packge build-deps.
So, athinfod-cluster-config build-deps on athinfod. And athinfod deps on machtype, so machtype gets added to athinfod-cluster-config's build-deps.

[jdreed]

The attached patch fixes this, though because of things like libathdir0, it generates multiple identical lines for some packages. I think Make won't care if there are two identical lines, right?

[jdreed]

Since nobody whined, committedin r25587. The duplicate lines are irrelevant, since the package will be built, the .done file will exist, and it will be a no-op.

[jdreed]

This worked fine for the Squeeze build and is deployed in the locker.