[petsc-dev] configure using stale packages

[Jed Brown]

"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.