[petsc-dev] configure using stale packages

[Balay, Satish]

On Fri, 28 Jun 2019, Jed Brown wrote:

> "Balay, Satish" <balay at mcs.anl.gov> writes:
> 
> > On Fri, 28 Jun 2019, Jed Brown via petsc-dev wrote:
> >
> >> If we configure with --download-pnetcdf (version 1.9.0), then update the
> >> PETSc repository to use a new version (1.11.2), then re-run ./configure
> >> --download-pnetcdf, we get a warning making us look like dolts:
> >> 
> >> ===============================================================================                                                                                                                
> >>       Warning: Using version 1.9.0 of package pnetcdf; PETSc is tested with 1.11                                                                                                               
> >>       Suggest using --download-pnetcdf for a compatible pnetcdf                                                                                                                                
> >> ===============================================================================
> >> 
> >> It looks like we have a mechanism for gitcommit versions, but not for
> >> normal numbered versions?
> >
> > Yes. We have some overloaded functionality here wrt --download-package
> > for tarballs.  This is to partly support:
> >
> > --download-package=URL
> >
> > [where URL could be a different version - or have a different dir structure in the tarball].
> 
> Right, I understand being permissive in that setting, but if someone is
> asking to use the package version defined in packages/foo.py, we should
> strive for configure to produce the same result as if we had deleted
> PETSC_ARCH and reconfigured from scratch with the same options.
> 
> > And then - our desire to avoid re-download the package if its already
> > downloaded.  Perhaps this part can be improved by stashing the tarball
> > somehow that corresponds to the URL used.. [but sometimes one can use
> > the same tarball with a different URL]
> 
> If we trust our former selves, perhaps we can record self.version at the
> time of a download and clean/re-download any time we're being asked to
> download a different version (e.g., because packages/foo.py has changed).
> 
> > Wrt a git repo, one can overcome this with:
> >
> > --download-package=git://URL --download-package-commit=HASH
> >
> > [but configure does not expect the URL to change after a clone is
> > created - so that part can break]
> 
> Yes, I had to manually fix this in about a dozen PETSC_ARCHes after the
> Hypre repository moved.

Barry's new feature of creating a PETSC_ARCH-hash can presumably avoid these
problems. [it might build more PETSC_ARCHes than necessary - but can
perhaps avoid such issues.

Satish