Dependancies on deployments don't work as expected

[GoogleCodeExporter]

A package which has a deployment listed as a prerequisite will happily build 
even if the deployment is out-of-date.  

Steps to reproduce the problem:
  1. muddle build package-a
  2. muddle deploy package-a
  3. <edit package-a source>
  4. muddle rebuild package-a
  5. muddle rebuild package-b-that-depends-on-deployed-package-a

This will create a package-b that *looks* like it's up-to-date, but has, in 
fact, been constructed with an out-of-date package-a.

The issue can be further masked since steps 4 and 5 might actually have been a 
top-level muddle-with-no-arguments.

While it's good that we don't automatically redeploy all the time, I think we 
should really try not to build bogus things by accident and then leave them 
lying around.  Perhaps deleting out-of-date deployments would offer a way 
forward.

Original issue reported on code.google.com by david.mu...@kynesim.co.uk on 11 Dec 2012 at 6:07

[GoogleCodeExporter]

This is a known problem, thanks for raising the issue.

The initial design of muddle assumed that dependencies would always be "down" 
or "across" the checkout->package->deployment ordering, so that we would not 
have packages depending on deployments.

Unfortunately, we ended up with builds that wanted to create CPIO archives to 
put "on the side" of kernel images, and the only way of generating CPIO 
archives has been via deployment. So such builds end up with this problem.

Issue 201 was raised to tackle that issue - it's still outstanding at time of 
writing.

Regardless, there is nothing to *stop* "forward" dependencies in muddle, and 
thus it should handle them "correctly".

Looking just at deployments, it may be that we need an extra tag, something 
like out_of_date (that's a bit aggressive) or pending (that's a bit unobvious), 
which indicates that the packages it depends on have been rebuilt, but the 
deployment has not been redeployed. Then when a dependency tree is being 
readdressed, and a deployment is inspected implicitly as part of that, it might 
get redeployed based on that tag rather than the absence of the "deployed" tag.

An alternative may be to mark deployments that are involved in such dependency 
chains, i.e., as non-terminals in the dependency tree, and treat them specially.

The important thing is not to cause redeployment of all deployments just 
because a package they use has been rebuilt.

Original comment by t...@kynesim.co.uk on 12 Dec 2012 at 10:29

• Changed state: Accepted

[GoogleCodeExporter]

Current plan is:

1. Make all the muddled.deployments mechanisms also work on packages (i.e., as 
has been done for cpio)

2. Fix all the build descriptions where a package depends on a deployment to do 
it instead using the new mechanism

3. Make it illegal for a package to depend on a deployment (thus neatly 
removing the problem)

4. When someone comes up with a reason for re-allowing a package to depend on a 
deployment, work out what they meant instead and implement *that*

Original comment by t...@tonyibbs.co.uk on 30 Jan 2013 at 2:14