[petsc-dev] Updating MOAB version during download

[Vijay S. Mahadevan]

>    Releases would ONLY list tar balls. Branches in petsc-dev (in git) could list either a tar ball or a git repository. Hence end users do not need git.
>
>    This would require that when making a release branch any git based urls would need to be replaced with tar ball ones. Which we kind of need anyways.
>

Just to clarify, for the release dependency, this would require hard
wiring a commit (tag of xx version) and/or a tarball file (release xx
version). And for the individual feature branches and/or master during
the dev cycle, these would point to either the git repo with a latest
commit hash or the nightly ?

>    well no. moab.py had hardwired some ancient git version of moab while the tar ball that it used was the nightly. So the git version did not match the tar ball version!

The nightly points to the latest commit in master and unless the
appropriate hash is also manually updated in moab.py after every MOAB
commit, these will not be in sync. I'm guessing this is how they
diverged to start with.

Vijay

On Mon, Jun 16, 2014 at 11:47 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> On Jun 16, 2014, at 11:29 AM, Satish Balay <balay at mcs.anl.gov> wrote:
>
>> 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.
>
>    Releases would ONLY list tar balls. Branches in petsc-dev (in git) could list either a tar ball or a git repository. Hence end users do not need git.
>
>    This would require that when making a release branch any git based urls would need to be replaced with tar ball ones. Which we kind of need anyways.
>
>>
>> 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']
>
>    I would also
>
>>
>>>
>>> 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'.
>
>    well no. moab.py had hardwired some ancient git version of moab while the tar ball that it used was the nightly. So the git version did not match the tar ball version!
>
>>
>> Satish
>>
>>>
>>>  Barry
>>>
>>>
>>>
>>>
>>>
>>> On Jun 16, 2014, at 9:53 AM, Satish Balay <balay at mcs.anl.gov> 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
>>>
>