Should BuildSystem download updated external packages when they are out of date?

[Barry Smith]

    This is easy enough if we have a way of knowing the package is  
"out of date". We could do it based on if the directory name matches  
the base part of the tarball file name that is being downloaded. This  
would work if the directory name is always the same as the base part  
of the tarball file name. Is this true?

    Then simply write a short message to the screen saying deleting  
old version, python unlink it and proceed as normal.


    Barry

On Oct 2, 2009, at 9:11 AM, Richard Tran Mills wrote:

> BuildSystem Folks (Matt, mainly),
>
> This is not really a problem for me since I know about this behavior  
> already, but I note that it can cause significant confusion when  
> configure.py has been asked to download a package and a very out of  
> date version of that package already exists in $PETSC_DIR/ 
> externalpackages.  In this case, configure.py doesn't do anything  
> since the package is already there, but in some cases the interfaces  
> have changed and that package isn't actually usable.  For instance,  
> if hypre-2.0.0 is present, it won't work with the current petsc-dev,  
> but the configure proceeds anyway, even though things won't work  
> unless hypre-2.4.0b is downloaded.  In such a case, deleting the  
> hypre-2.0.0 directory and re-running configure.py will fix the  
> problem, but it seems like this isn't very user-friendly and I know  
> that it does cause some confusion.
>
> I am no BuildSystem hacker (I think I've committed a change maybed  
> once, in 2005?).  Can someone tell me if it is reasonable to make  
> configure.py download the new package if the old one is too out of  
> date?
>
> Sincerely,
> Richard