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

[Matthew Knepley]

On Fri, Oct 2, 2009 at 9:11 AM, Richard Tran Mills
<rmills at climate.ornl.gov>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?
>

This is the versioning problem, which has no good resolution. The way I
understand things, with a given version of PETSc, this problem
cannot arise, UNLESS it is petsc-dev. I am willing to live with this problem
in petsc-dev, rather than introduce some versioning scheme
which is just as broken as the current scheme.

   Matt


> Sincerely,
> Richard
>
-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091002/77bddb79/attachment.html>