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

Matthew Knepley knepley at
Fri Oct 2 09:38:16 CDT 2009

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


> Sincerely,
> Richard
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the petsc-dev mailing list