I mistated one thing. The git-url usage in pacakge.py spills over to tarball users aswell.
Now to have consistant tarballs wrt git repo - we have to migrate all tarball urls to tarballs from the git repo hosting site. [and not host at ftp.mcs.anl.gov] But this is unreliable [the last I checked with elemental at github - git failed frequently - but it was giving out taballs more reliably] satish On Tue, 29 Oct 2013, Barry Smith wrote: > > Just because you can do it doesn’t mean you should do it. > > Barry > > On Oct 29, 2013, at 2:07 PM, Barry Smith <[email protected]> wrote: > > > > > It is not worthy any additional logic in the already messing configure > > process to save a few downloads. > > > > Barry > > > > > > On Oct 29, 2013, at 1:59 PM, Satish Balay <[email protected]> wrote: > > > >> On Tue, 29 Oct 2013, Jed Brown wrote: > >> > >>> Barry Smith <[email protected]> writes: > >>>> Or simpler just have the —with-clean nuke external packages; makes > >>>> life easy. By "store the tarballs in a common place” and SHA1 crap > >>>> you are making the system more complicated to understand and > >>>> maintain. > >>> > >>> People will complain when they have to download the same tarball many > >>> times. But I don't especially care as long as the builds are done > >>> inside $PETSC_ARCH instead of in a common place. (This is also useful > >>> when building multiple configurations of PETSc in parallel.) > >> > >> There is also the issue with git repos to deal with. [presumably the > >> above logic would be slightly different than the tarballs] > >> > >> We [Jed and I ] also discussed having git repos and corresponding > >> tarballs match - and caching tarballs locally for unreliable external > >> sites. And then using SHA as a way of versioning to eliminate most > >> cases where with-clean would be needed. > >> > >> Just a note: all these issues are primarily with git users - not > >> petsc-release/tarball users. > >> > >> Satish > > > >
