MacPorts 1.5.2 now available

[Ryan Schmidt]

On Aug 31, 2007, at 03:36, Vincent Lefevre wrote:

> On 2007-08-29 20:28:30 -0500, Ryan Schmidt wrote:
>
>> But we always want users to compile MacPorts base using the gcc
>> provided with Apple Xcode. We don't want people attempting to use
>> any other version of gcc.
>
> Does MacPorts ensures that Xcode gcc is used?

I don't know. Several hundred ports do, though, and it's my belief  
(see thread "[28325] trunk/dports/graphics/wxWidgets-devel/Portfile"  
on macports-dev) that MacPorts base should ensure that all ports use  
Apple's gcc, unless the port specifies otherwise.

>>> Couldn't MacPorts be made compatible with the GNU readline API?
>>
>> I thought it already was. I think the problem is not that MacPorts  
>> is not
>> compatible with GNU readline, but that users sometimes have  
>> incredibly old
>> versions of readline in /usr/local which are (apparently)  
>> insufficient for
>> MacPorts. We don't want to link against incredibly old (or even up- 
>> to-date)
>> versions of software the user has installed themselves.
>
> Then that's a user-side problem. The best fix is to remove/replace  
> this
> incredibly old version of readline.

Of course. But if MacPorts *seems* to build correctly against this  
old readline, and several ports *seem* to build correctly against the  
old readline, and the user doesn't even know the old readline is  
there because some other 3rd-party software they wanted installed it  
there for them, and then one day they want to build db44 and it  
throws bizarre errors that nobody figures out how to fix for months  
[1], then this gives the impression that MacPorts is unreliable. So  
it *becomes* our problem to ensure the user doesn't make these kinds  
of mistakes. It is documented that we want MacPorts to use only its  
own software, or Apple software in if required in a pinch, so we  
should make MacPorts behave in accordance with that documentation.

[1] http://trac.macosforge.org/projects/macports/ticket/12040

>> We want to use software managed by MacPorts where at all possible.
>> ANnd for the bootstrapping process of of initially getting MacPorts
>> installed, it's reasonable to use just Apple software.
>
> But Apple software has bugs. For instance, its readline doesn't  
> support
> UTF-8. I don't know if it can be useful, but anyway the user could  
> type
> non-ASCII characters by mistake, try to remove them, leading to wrong
> commands.

Well I have no idea about that but if it's important, then MacPorts  
should include an updated readline and use that exclusively. And if  
it's not important, then it should use Apple's readline. The point  
remains that MacPorts should *not* use some arbitrary readline in / 
usr/local.