On Mar 30, 2005, at 6:16 PM, Michael G Schwern wrote:
On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote:Should we completely open this up so that requires/recommends/conflicts
can be applied to any action?
install_recommends => ... testcover_requires => ... etc.
This sounds useful and solves a lot of problems at one sweep. You can use
the existing dependency architecture to determine what needs what. Such as
testcover needs both test_requires and testcover_requires.
There's a problem with this that I'm not sure how to solve: what happens when, as part of refactoring, a chunk of one action gets factored out to become its own sub-action? The dependency may well pertain to the new sub-action instead of the original action, but distribution authors won't have any way to know this - or even if they did, they couldn't declare it in a forward-compatible way.
This is precisely the problem we're hitting with 'build_depends' vs. 'code_depends'. At one time, the 'build' action was a dependent of the 'test' action. So under our proposed dependency model, everything would work fine: before running the 'test' action, you run the 'build' action, which checks 'build_depends'.
Then we perform refactoring, and we create a 'code' action that the 'build' and 'test' actions both can depend on. The distribution author still declares dependencies using 'build_depends', though - so when we run the 'test' action, we first run the 'code' action, which has no declared dependencies, and we end up with a nasty runtime error rather than a nice specific error about dependencies.
Any solutions I'm missing?
-Ken
