[9217] in athena10
Re: [Debathena] #1089: gen-build-deps only reflects one level of
daemon@ATHENA.MIT.EDU (Debathena Trac)
Fri Jun 8 12:31:48 2012
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@MIT.EDU
To: jdreed@MIT.EDU
Date: Fri, 08 Jun 2012 16:31:43 -0000
Reply-To:
Message-ID: <057.4aa4b3ee28b5d8bf06a2937fb15b3db5@mit.edu>
In-Reply-To: <042.64324cecd9d8701569947fa631fe0546@mit.edu>
Content-Transfer-Encoding: 8bit
#1089: gen-build-deps only reflects one level of depth
--------------------+------------------------------
Reporter: jdreed | Owner:
Type: defect | Status: new
Priority: high | Milestone: Precise Alpha
Component: -- | Resolution:
Keywords: | Upstream bug:
--------------------+------------------------------
Comment (by 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.
--
Ticket URL: <https://athena10.mit.edu/trac/ticket/1089#comment:1>
Debathena <http://debathena.mit.edu>
MIT Debathena Project
