I am getting into this thread a little late. What is, exactly, what we need 
to change with ./configure ; make ; make install to make the PETSc "upstream 
installation" not a mess?  Are we simply over installing stuff? (This could 
be). Is it the optional dependency handling? 

   In bin we have , that probably belong elsewhere. 

   You should feel free to make branches that move this kind of stuff to more 
appropriate places and stop installing unneeded crap, but you can't expect 
someone else on the PETSc team to magically fix misinstalls and you need to be 
proactive as well.


   It is important to follow "standards" when possible even if they are a bit 
annoying so long as they don't totally ruin the user experience. Our current 
install is not written in stone and can be adjusted to make package people 
happy if possible.

> On Feb 23, 2018, at 2:19 PM, Jed Brown <> wrote:
> What, if anything, really needs to be installed to $prefix/bin?
> From the Homebrew lead maintainer.
> From: Mike McQuaid <>
> Subject: Re: [Homebrew/homebrew-core] PETSc: import from homebrew-science 
> (#23598)
> Date: February 23, 2018 at 1:59:53 PM CST
> To: Homebrew/homebrew-core <>
> Cc: Jed Brown <>, Mention <>
> Reply-To: Homebrew/homebrew-core 
> <>
> doesn't this attitude complete defeat the purpose of a package manager?
> You're asking of the hardest working package manager maintainers in the world 
> (@ilovezfs). Chances he has a better idea about the purpose of a package 
> manager than you do.
> I cannot understand not wanting a package because it is complicated to 
> install.
> This is perhaps because you do not maintain a package manager.
> What you're suggesting is that any software using PETSc should either force 
> users to compile it from scratch or discontinue supporting macOS entirely.
> No, what's being suggested is that PETSc's currently upstream installation is 
> a mess and we don't want to maintain the hacks required to make it not one 
> indefinitely. You can copy and paste this formula as-is into a tap and it'll 
> work for you just fine.
> That seems like the wrong approach for a package manager.
> In the package manager you maintain you should take a different approach, 
> then.
> Just my opinion...
> If you have to end your statement like that: it's probably worth keeping 
> quiet in future, please.
> To be clear, I'm not being harsh here because I like doing so but because 
> this entitled, know-it-all attitude literally kills open source projects and 
> @ilovezfs's motivation is more important to me than allowing that to go 
> unchallenged.
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.

Reply via email to