On Tuesday, January 28, 2014, Sean Farley <[email protected]> wrote:
> > [email protected] <javascript:;> writes: > > > On Jan 28, 2014, at 12:14 PM, Geoff Oxberry > > <[email protected]<javascript:;>> > wrote: > > > >> > >> > >> > >> On Tue, Jan 28, 2014 at 9:10 AM, Sean Farley < > [email protected] <javascript:;>> wrote: > >> > >> [email protected] <javascript:;> writes: > >> > >> > To echo what Aron said, I wouldn't point people at the > >> > hpc.sourceforge.netbuilds. They do install directly into /usr/bin, and > >> > it's a pain in the ass > >> > >> 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). > > Sigh. It is this type of curmudgeon behavior that pushes away people > from helping out with these type of projects. Packagers are just > volunteers and to estrange the current three (yes, three) would be > unfortunate. Not many (read: none) of the other devs care about having > multiple compilers (thanks, fortran) nor pandering to the scientific > community's lack of good software practices. > > Agreed. > It is no secret that MacPorts has historically flubbed on lots of > PETSc-related issues. I have been trying to change this perspective > but this email thread pretty succinctly explains what makes my job > difficult. Also agreed; the other package managers suffer from this problem as well. > Just look at how difficult it is to install these packages: superlu, > superlu_dist, metis, parmetis, scotch, scalapack, and mumps. > > The comments here do nothing but drive away users and frustrate > potential collaborators. Not just for PETSc but for any project that > depends on PETSc (SLEPc, FEniCS, MOOSE, etc). The true disservice to the > community is forcing each user to manage their own packages. Absolutely. Most scientists don't care about these issues until it bites them in the ass. > Instead of criticizing here, the energy could be better spent by > contributing. > Couldn't agree more. Had I not had a bad experience with MacPorts, I would be using SciencePorts, and I think it's important to work on packaging issues. My biases aside, I hope MacPorts improves, and I think it's good that you're working on it. -- Geoffrey Oxberry, Ph.D., E.I.T. [email protected]
