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

[Juan Manuel Palacios]

On Nov 18, 2007, at 6:47 AM, Anders F Björklund wrote:

> Juan Manuel Palacios wrote:
>
>> 	And while we're at it, I just created an rc2 tag for 1.6.0,  
>> differing from rc1 only in James' turning readline support into an  
>> optional configuration (r31139-31139 and merged into the  
>> release_1_6 branch in r31190) and in the Tcl cd command hiding  
>> reversion thing (r31193 only in the release_1_6 branch). Every  
>> developer/committer should reinstall MacPorts off this tag and test  
>> as extensively as possible!
>
> The HACKING file is still present, and the README file is still  
> missing... ?


	All our documentation will definitely be moved to the guide,  
including the usual INSTALL, README, HACKING and similar text files  
found in open source projects. We already have some of these and we  
lack others, some are already in the guide and some still in our  
sources, but they will all eventually end up there, as our  
documentation authors manage to get to each of them.

	Nevertheless, I say we keep the usual suspects in our sources but  
only as placeholders pointing readers to the relevant sections in the  
guide. What do you suggest we put in a README file?

>
>
> Not sure if you wanted http://trac.macports.org/projects/macports/ticket/13141
> to be in 1.6,


	That would be sweet! Do you have any ETC/deliverables? I added a  
small comment to the ticket which might be of help.


> or just http://trac.macports.org/projects/macports/ticket/12779


	This relating only to the guide, it would be great to have it for the  
time we release 1.6.0 too, but I don't think we need to tie ourselves  
to it; it can happen at any moment (the guide is regenerated nightly).

>
>
> Checking Xcode version, http://trac.macports.org/projects/macports/ticket/12794 
> ,
> is present on compile time but there are no warnings for binaries or  
> upgrades.


	I like this idea and made some comments on the ticket just now. Is it  
something we can expect for 1.6.0? (regarding maturity of the idea and  
time to implement it)

>
>
> Maybe look into http://trac.macports.org/projects/macports/ticket/ 
> 8401 and reopen


	Doable. Made a comment on the ticket, feedback would be great.

>
> 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.

	But as I said, I'm not happy about the state of things so I'll try  
again looking into it, but I wont make any promises.

>
>
> I probably won't be updating MP 1.6 to RPM 4.5 and Python 2.5 for  
> the rpm packaging
> targets/ports, as I had originally intended. (It'll still use RPM  
> 4.4 / Python 2.4)


	Not a problem, whenever you're ready!

>
>
> Will make a "MacPorts-1.6.0RC2.tar.b2" tarball for testing other  
> platforms tonight.
>


	Great! Let us know of status.

> --anders
>


	Regards,...


-jmpp