Ticket #1089 (closed defect: fixed)

Opened 10 years ago

Last modified 9 years ago

gen-build-deps only reflects one level of depth

Reported by: jdreed Owned by: jdreed
Priority: high Milestone: Precise Beta
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

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?

Attachments

gen-build-deps.patch Download (2.0 KB) - added by jdreed 9 years ago.

Change History

comment:1 Changed 9 years ago by jdreed

  • Summary changed from make -k all doesn't to gen-build-deps only reflects one level of depth

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.

Changed 9 years ago by jdreed

comment:2 Changed 9 years ago by 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?

comment:3 Changed 9 years ago by jdreed

  • Status changed from new to accepted
  • Owner set to jdreed

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by jdreed

  • Status changed from accepted to committed

comment:6 Changed 9 years ago by jdreed

  • Status changed from committed to closed
  • Resolution set to fixed

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

Note: See TracTickets for help on using tickets.