Is there a decent package manager we can simply use or adapt for our purposes (written in Python, of course)?<div><div>I'm guessing the answer is "No", but I thought I'd ask anyway.</div><div><br></div><div>

Dmitry.<br><br><div class="gmail_quote">On Tue, Aug 30, 2011 at 2:34 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On Tue, 30 Aug 2011, Jed Brown wrote:<br>
<br>
> On Tue, Aug 30, 2011 at 14:24, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> > The Satish way (which is always the correct way) is to do rm -rf<br>
> > ${PETSC_ARCH} and then run ./configure again.<br>
><br>
><br>
> Yes, but the run-time of this operation is 2^{1 + millions of dollars paid<br>
> for machine} minutes so it clearly won't work at the exascale. You're going<br>
> to be left in the past if you keep thinking like that.<br>
><br>
><br>
> More seriously, rm -rf ${PETSC_ARCH} is horrible because you lose<br>
> reconfigure-$PETSC_ARCH.py if you don't relocate it first.<br>
<br>
</div></div>Yes - this is one drawback. Also there is another issue that 'rm -rf'<br>
adresses that --download-package=reinstall can't do easily [without a<br>
proper traker and uninstaller]<br>
<br>
All --download-package=reinstall can do is install the new one over<br>
the old one. This can can still break if the new one doesn't<br>
completely overwrite the old one.<br>
<br>
One example: --download-superlu can change from installing<br>
-lsuperlu4.1 to -lsuperlu4.2. Perhaps there are other suttle breakage<br>
senarios aswell..<br>
<font color="#888888"><br>
Satish<br>
<br>
</font></blockquote></div><br></div></div>