[petsc-dev] elemental in nightly builds with g++-4.6

[Satish Balay]

On Wed, 9 Oct 2013, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> > When we add git URLs - we should update the tarball URLs to equivalent
> > git snapshots.  The intent for the multiple url support in package.py
> > is to be able to get the same source via multiple paths.
> >
> > So perhaps the tarball URL should be: https://github.com/elemental/Elemental/archive/master.tar.gz
> 
> No, because that updates with no action on our part.  If Jack changes an
> interface, our --download-elemental would fail.  We want someone to
> certify that an upgrade works.

in this case the url would be https://github.com/elemental/Elemental/archive/89e7ddc52db68dc5a3f2635733293d7349dbd518.tar.gz

> > [or the url automatically crated from self.giturls + self.gitcommit . note: bitbucket appears to use 'get' instead of 'archive']
> 
> Yeah, so long as there is nothing special in generating a release
> tarball.  (PETSc generates ftn-auto, for example.)

yeah. but all that stuff would be genreted for the git clone anyway. [and I think petsc configure
might have smarts to say 'git-clone and git-tarball are equivalent - release tarball is different'

> > But switching from elemental-dev to elemental-release should be a different matter.
> > [both git & tarball urls should probably changed simultaneously]
> >
> > Presumably we won't have fallback tarballs for git repos on ftp.mcs
> 
> Those fallback tarballs are currently a maintenance issue.  Can we automate it?

Hm - currently updating the url in package.py is a manual process. so
updating ftp.mcs would be done at the same time.

But if we want some kind of automatic fallback for all urls - perhaps we
can setup a squid-proxy cache at mcs - and configure always uses that?
[maybe it won't work for all cases..]

Satish