On Tuesday, January 28, 2014, Satish Balay <[email protected]> wrote:
> On Tue, 28 Jan 2014, Barry Smith wrote: > > > > > > > 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. > > > > 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). > > > > My view is: anyone using OSX has bought into the idea of not having a > proper package management system. [yeah you get easy-install packages > - but most of them don't have an proper way to uninstall - unless its > an "osx-app" which you can drag/drop into trash] > > gfortran from hpc.sourceforge does things "no worse" than most packages > that are available for OSX. > > Its not obvious - but one can use the file listing from the tarball [as > mentioned in my previous e-mail to uninstall]. And is tucked away > in /usr/local - so it doesn't do any damage like other packages. 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. > [for eg: install mercurial for OSX - and see if you can uninstall it] 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. > I agree a better package management system [aka macports/homebrew] > should be preferable. But with all the wierd issues that keep comping > up with users using macports on petsc lists - I can't convince myself > that it is a better recommendation. > > perhaps homebrew is better - I don't know. 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. I would not recommend MacPorts either; I don't use it. Sean knows more about this than I do and can better defend MacPorts. 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). 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. 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. I would aswell recommend virtualbox with linux as a superior choice. > > Satish > 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. 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. -- Geoffrey Oxberry, Ph.D., E.I.T. [email protected]
