Please review: proposed dependency handling change

[Jordan K. Hubbard]

On May 5, 2008, at 5:59 PM, Joshua Root wrote:

> The full enhancement requested by the ticket will (AFAICT) be rather  
> difficult to implement at present. I have however attached a patch  
> which improves things a bit. It makes 3 things better:
>
> 1. You can use depends_build for software that needs to be used in  
> the extract or patch phases. This helps e.g. python23 which needs  
> gnutar for extract.
> 2. You can use depends_build for software that is needed for the  
> configure phase but not at runtime (e.g. pkgconfig). Currently  
> depends_build is not checked until after the configure phase.
> 3. Dependencies weren't being checked when running some packaging  
> targets. Now they are.

This raises an important question:

Is there any value in creating depends_foo procs for each reasonable  
value of foo, even if they are just aliases for depends_build in the  
short/medium/forever term?

Pros:
	There is some documentary value to being able to say depends_extract  
<blah> or depends_configure <feh> even if they just fold to  
depends_build since it's clearer from the declaration just why the  
dependency is needed.

	At some point, there might be real value to distinguishing between  
the types of dependencies.  Say you were going on a business trip and  
looked forward to having plenty of spare CPU/disk cycles to build  
stuff on your laptop but not such great internet connectivity.   You  
might do "port fetch bar" and expect it to only pre-populate your  
distfile cache, plus any tools the dependencies for bar might need  
just for fetching, but not actually build anything.

	Might be less confusing than trying to explain that there are really  
only two umbrella dependencies types even though there are lots of  
different possible targets.

Cons:
	Adds complexity, namespace bloat.