<br><br>On Tuesday, January 28, 2014, Sean Farley <<a href="mailto:sean.michael.farley@gmail.com">sean.michael.farley@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'bsmith@mcs.anl.gov')">bsmith@mcs.anl.gov</a> writes:<br>
<br>
> On Jan 28, 2014, at 12:14 PM, Geoff Oxberry <<a href="javascript:;" onclick="_e(event, 'cvml', 'goxberry@gmail.com')">goxberry@gmail.com</a>> wrote:<br>
><br>
>><br>
>><br>
>><br>
>> On Tue, Jan 28, 2014 at 9:10 AM, Sean Farley <<a href="javascript:;" onclick="_e(event, 'cvml', 'sean.michael.farley@gmail.com')">sean.michael.farley@gmail.com</a>> wrote:<br>
>><br>
>> <a href="javascript:;" onclick="_e(event, 'cvml', 'goxberry@gmail.com')">goxberry@gmail.com</a> writes:<br>
>><br>
>> > To echo what Aron said, I wouldn't point people at the<br>
>> > hpc.sourceforge.netbuilds. They do install directly into /usr/bin, and<br>
>> > it's a pain in the ass<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>
Sigh. It is this type of curmudgeon behavior that pushes away people<br>
from helping out with these type of projects. Packagers are just<br>
volunteers and to estrange the current three (yes, three) would be<br>
unfortunate. Not many (read: none) of the other devs care about having<br>
multiple compilers (thanks, fortran) nor pandering to the scientific<br>
community's lack of good software practices.<br>
<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is no secret that MacPorts has historically flubbed on lots of<br>
PETSc-related issues. I have been trying to change this perspective<br>
but this email thread pretty succinctly explains what makes my job<br>
difficult.</blockquote><div><br></div><div>Also agreed; the other package managers suffer from this problem as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Just look at how difficult it is to install these packages: superlu,<br>
superlu_dist, metis, parmetis, scotch, scalapack, and mumps.<br>
<br>
The comments here do nothing but drive away users and frustrate<br>
potential collaborators. Not just for PETSc but for any project that<br>
depends on PETSc (SLEPc, FEniCS, MOOSE, etc). The true disservice to the<br>
community is forcing each user to manage their own packages.</blockquote><div><br></div>Absolutely. Most scientists don't care about these issues until it bites them in the ass.<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Instead of criticizing here, the energy could be better spent by<br>
contributing.<br>
</blockquote><div><br></div><div>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.</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>