<br><br>On Tuesday, January 28, 2014, Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 28 Jan 2014, Barry Smith wrote:<br>
<br>
> ><br>
> > Satish is probably right here about the build location. It's been three or four years since I've installed it this way. I stand by that it's still difficult to revert. I actually tried this method because of PETSc and regretted it because the experience was terrible. Using a package manager is more maintainable, and I think PETSc's recommendation of the hpc.sourceforge build is a disservice to both users and to PETSc's excellent reputation.<br>

><br>
>    I think package managers for Mac OS are a disservice to the community and recommend not using them. (See all the discussions in these emails about how they fuck up).<br>
><br>
<br>
My view is: anyone using OSX has bought into the idea of not having a<br>
proper package management system. [yeah you get easy-install packages<br>
- but most of them don't have an proper way to uninstall - unless its<br>
an "osx-app" which you can drag/drop into trash]<br>
<br>
gfortran from hpc.sourceforge does things "no worse" than most packages<br>
that are available for OSX.<br>
<br>
Its not obvious - but one can use the file listing from the tarball [as<br>
mentioned in my previous e-mail to uninstall]. And is tucked away<br>
in /usr/local - so it doesn't do any damage like other packages.</blockquote><div><br></div><div>If you follow the relative install paths, yes, your method does the job. It's what I did, with some testing, and then I reinstalled the XCode Command Line Tools. As long as a user is careful, no harm done; it's also easy to mess up. You could do something similar via lsbom for packages in OS X and/or delete via the package identifier using pkgutil and largely only leave behind plist files. This method is what homebrew-cask uses for managing OS X binaries.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[for eg: install mercurial for OSX - and see if you can uninstall it]</blockquote><div><br></div><div>For Mercurial, I'd install & uninstall via pip and a virtualenv. Your point is well-taken for packages in general, and can still be managed (see above). Uninstall apps will also do the job.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree a better package management system [aka macports/homebrew]<br>
should be preferable. But with all the wierd issues that keep comping<br>
up with users using macports on petsc lists - I can't convince myself<br>
that it is a better recommendation.<br>
<br>
perhaps homebrew is better - I don't know.</blockquote><div><br></div><div>You guys do the support work (and do a good job of it), so I defer to your judgment here. My opinion was borne out of a bad experience and trying several methods of installation; I apologize for the brief burst of impertinence.</div>
<div><br></div><div>I would not recommend MacPorts either; I don't use it. Sean knows more about this than I do and can better defend MacPorts.</div><div><br></div><div>With Homebrew, it should be possible to replicate the current recommendation and only install six additional packages (cloog, gmp, isl, mpfr, libmpc, and pkg-config).</div>
<div><br></div><div>Mixing gfortran 4.8 with the rest of the gcc 4.2 or clang 3.3 stack can also be tricky, which was my point about different compiler versions. SciPy recommends the AT&T build and states that problems may arise with the hpc.sourceforge build; as you pointed out, this version causes problems for PETSc. So I tend to use multiple builds of PETSc in different PETSC_ARCH directories; one of these builds is a gcc 4.8 build because PETSc is relatively self-contained (which is a testament to your design and build system), so I'm not terribly worried about system library conflicts.</div>
<div> </div><div>My Python rant is not a good argument for hpc.sourceforge (or against package managers) because sitewide installs of interpreted language packages -- especially via an OS package manager -- should be minimized, regardless of operating system or distribution. Otherwise, you run into problems like pip trying to overwrite system libraries.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would aswell recommend virtualbox with linux as a superior choice.<br>
<br>
Satish<br>
</blockquote><div><br></div><div>Probably the best choice. Even then, some can't run virtual machines (I can't at work), and OS X is a lesser evil than a Windows machine. </div><div><br></div><div>As Jed points out, manual installation is difficult to maintain. Fixing a package manager is my best path forward (not getting a different job); they're not perfect, but they won't get better unless people work on them. I agree with Matt that most of this discussion is ideology.</div>
<br><br>-- <br><div dir="ltr"><span></span>Geoffrey Oxberry, Ph.D., E.I.T.<br><a href="mailto:goxberry@gmail.com" target="_blank">goxberry@gmail.com</a><br><span></span></div><br>