py26-numpy +gcc44 requires gcc45 variant of atlas

[Keith J. Schultz]

Hi Jeff,

Am 15.09.2010 um 21:14 schrieb Jeff Singleton:

> Well ... 
> 
> I can honestly say, I get all of your points.  Not that I didn't before, but it is definitely clear now.
> 
> I am even less of a developer that the newest maintainer here, so I can only point out what doesn't seem correct, or isn't working.  I can read code, and on rare occasions fix minor issues derived from error messages.
	
> 
> Ryan ... I say I should be able to choose which Arch that I want to build under if my hardware supports it, sometimes it isn't proper to just accept whatever the compiler chooses.  Sometimes preference of the end user should dictate how things should and shouldn't work...not the hardware.  If I have a need for 32-bit, then that is my need and no one should tell me that I can't build code in 32 bit on hardware that is natively 64 bit...if the compiler supports it, then I should be able to tell it to do so.
	Well, maybe MacPorts is not for you! You could always use Fink.
	Get the original sources from the original developers and build from there. You have all the freedom you need.
> 
> As for the manpower thing ... well I guess that is something that may not change or could change dramatically. Possibly a bit of marketing of MacPorts might attract some talent.  Yet, as far as I know, every Linux distribution aside from Redhat and Suse is a volunteer based community of developers/maintainers...and even Redhat and Suse have community driven forks that help drive the development of the mainstream distros.  So what makes MacPorts any different from all those others, is it popularity or a lack thereof?  Do enough people know about MacPorts and how closely it relates to BSD ports? I suppose if just waiting around for someone to stumble across MacPorts and see they can offer some talent to maintaining some ports is ok, then MacPorts will just continue to move at the pace it is now.
	For one thing most Mac users do not live in the BSD or *Nix world. A good portion of Linux user on the other hand do in the Linux world and are interested in ports !
	So they have a lot more man-power. 
> 
> Besides, everyone can't be a coder, someone needs to actually use this stuff or else no one would ever know anything was broken.  Developers always seem to take offense when a user points out a flaw, and thus deeming the reporting user as point man for patching or updating the code themselves.
	Here, you are completely unfair. Evidently, you do not understand what is done at MacPort. They do not simple have a distribution system and patches that they make are tested. 
       I am sure they use the programs otherwise why should they be volunteer maintainers. They have a interest that things work.  
> 
> The fact is, coding and maintaining said code is what you developers do best.  Information Security is what I do best....and as such, I would never divert an issue needing my attention on to the person reporting the issue. Because of the nature of my work, doing so would almost guarantee that the network I am protecting is exposed.
> 
> So .. if upstream is deemed responsible for fixing a code issue then how do we bring this to their attention?  Are the Trac bugs ever viewed by upstream or referenced in other bugs opened with the upstream issue tracker?  How can I escalate a Trac bug from MacPorts to the upstream owners of the code in question?
	The big question is if the upstream is interested in developing or changing code to work with systems it is not interested in or cares about or hardware archs they are do not need!
	Or do have people prove who they have with hardware before they can access any information of your network. (aka thumb print, chip cards, etc) or is a password enough!

	regards
		Keith.