1.6.0 rc2 created (Was Re: [31193] branches/release_1_6/base/src)

[Ryan Schmidt]

On Nov 21, 2007, at 00:29, Juan Manuel Palacios wrote:

> On Nov 20, 2007, at 4:02 AM, Anders F Björklund wrote:
>
>> Juan Manuel Palacios wrote:
>>
>>>> http://trac.macports.org/projects/macports/ticket/13145 as well  
>>>> (preflight stuff)
>>>
>>> Though I'm not incredibly happy with the state of this issue, it  
>>> is a matter of fact that dealing with paths containing spaces can  
>>> turn into a major headache for us (and I'm not just referring to  
>>> MacPorts itself here, I can't imagine the thousands of ports that  
>>> we distribute that might hide this type of bugs in their  
>>> configurations and/or Makefiles.... uuughhh!). I tried  
>>> bootstrapping MacPorts into a path with spaces and couldn't even  
>>> get through our own configuration script, let alone get to my  
>>> dp2mp-move upgrading rules to try to bullet-proof them. I know  
>>> the original poster's problems creeps up when I try to upgrade  
>>> his personal configuration file, as it's the path to his home dir  
>>> what contains spaces and not MacPorts' prefix, but it's basically  
>>> the same situation.
>>
>> I'm not suggesting that paths with spaces should be supported. I  
>> just wanted *volumes* with spaces in their names to be supported,  
>> while still installing in the usual /opt/local prefix locally on  
>> the volume... The original poster mentioned that a manual install  
>> works just fine, it's just the preflight script in the package  
>> that is referring to things with "/Volumes/Litter Box" prefixed to  
>> the regular paths ? I know someone else wanted to install in their  
>> home folder, while it was located on a path with spaces, but that  
>> is an issue "for later"...
>
> OK, will definitely try to fix it for that scenario. However, my  
> recommendation still stands: avoid paths with spaces in them if  
> possible!

Right. I don't see why it would matter where in the path (volume  
name, not volume name) spaces occur; spaces anywhere in the path are  
not going to be acceptable to a whole lot of build scripts. I once  
submitted a bug against a popular package asking them to support  
spaces in paths, and it was closed as wontfix.

MacPorts itself should be made to fail (with an intelligible message)  
if installed to a prefix with a space anywhere in it, to avert any  
such problems that users would inevitably run into later.