On Mon, 16 Jun 2014, Barry Smith wrote: > > This email thread is way to complicated for me. Is the final decision > > 1) If a git and .tar.gz are BOTH given for a —download then they should > represent the same thing?
The defaults in package.py should match. Right now --download-package=URL can take .tar.gz stuff - but not a git URL [as far as I can remember] > > Sounds reasonable. (But why have both, just incase a website is down?) > How do we make sure they always match? They will get out of synch! I think the thought was [Jed, Matt should correct me] - if the user has 'git' installed - then configure should prefer downloading 'git' url. [else .tar.gz url] Currently git URL has proper checksum [enforced by git] - but the tarball one doesn't. The git url stuff needs further work - to add desired features - if URL changes - automatically get the changes. This is not possible with tarballs. - perhaps automaticall get tarballs from the git-prepo [if desired]. The -ve for using git is - the build process can be different [might have to start at 'autoconf' step - and not 'configure' step. Perhaps there are others. [tarball from git rep has is halfway between release tarball and git repo] > > My feeling is that ONLY a git OR a .tar.gz should be listed at any one > time and not both at the same time (the other should be commented out). The issue is - that would require all users having git installed. Currently we handle [all list entries as equivalent: url =[ 'http://url1/foo.tar.gz', 'ftp://url2/foo.tar.gz'] Matt would like us to hanlde: url = [ 'git://git-url', 'http://url1/foo.tar.gz', 'ftp://url2/foo.tar.gz'] > > 2) There is no logic in package.py for downloading different versions of a > package based on if PETSc is obtained from a tar ball or from git or in a > branch or not? Instead the user “knows” and uses —with-moab-dir or > —download-moab=somename.tar.gz to get the matching package. yes. > > I am not sure I like this, requiring someone to just “intuitively know” > what moab version they should be using with any particular development branch > is bullshit. My assumption here is - the default will continue tow work [so the tests with default would work] And then an additional test with moab-nightly - to verify if moab-nightly would continue to work. And If the default does not work anymore [due to petsc-dev/moab-dev interface changes] - then the default should be updated to a known snapshot that works. > Also for nightly tests of next and master it may not be the release of moab > or the nightly of moab that is compatible with the test; every time I merge > something into next (or master) I need to go to the nightly test scripts and > put in the proper location of all the packages, nonsense! Hm I didn't think about the same tarball for master and next (and maint). That might not work. > I think the correct fix is for the values in moab.py (for each package) > are changed over time and may be different in different branches and then at > a release they are “locked” into the correct value for that release. Yes, > this may mean manually setting some of the values when the release branch is > made. Tough, there is no way around it. This is fine by me. This is what we do with every other package. We could keep updating moab-snapshot-xxx.tar.gz as required. Thei issue came with MOAB becase at some point we decided 'petsc-dev should always use latest moab-dev'. Satish > > Barry > > > > > > On Jun 16, 2014, at 9:53 AM, Satish Balay <[email protected]> wrote: > > > On Mon, 16 Jun 2014, Vijay S. Mahadevan wrote: > > > >>> BTW: Is DMMoab in next different than in master? - is so - which > >>> branch is it coming from? [perhaps this update should go into that > >>> branch] > >> > >> This is in my feature branch whose PR was merged onto next recently. > >> Yes, as it stands, the DMMoab interface in next is different than > >> master and so the API version against which its linked needs to be > >> updated. I can make this change also in the branch if we decide on the > >> way forward. > > > > I just ran tests with moab-4.6.3 with petsc-master - and that went > > fine. Looks like the new tarball will work with either version of > > DMMoab [master vs next] > > > > So I could easily push this change to master. > > [But will wait for Barry's comments] > > > > I guess Jed or Barry will figureout when this PR will be merged to > > master. > > > > Satish > >
