On Wed, 9 Oct 2013, Jed Brown wrote: > Satish Balay <[email protected]> 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
