Front page | perl.qa |
Postings from April 2005
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? -KenThread Previous | Thread Next