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

[Anders F Björklund]

Juan Manuel Palacios wrote:

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

So does that means that it is now hands-off for everyone else, like  
with the manual pages ?

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

Just a dozen lines or so describing what it is, where it is, what it  
does and who did it.
Like in  
http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ 
distpractice.html#README

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

Nah, myself I just thought the available pkg information should be  
better.

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

Guide and Website, it was. As in: wherever the Download link is  
presented.

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

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

Since RPM 4.5 has not been released yet and since not all of the other  
ports work with Python 2.5 yet, it won't be a priority this year.  
Besides, RPM 5.0 is where the development happens - and it is currently  
in alpha testing.
The only major casualty of sticking with 4.4/2.4 is the Smart GUI,  
since it needs GTK+ and the "py-gtk2" port isn't available anymore.  
Then again the Smart text interface is still working OK, once python24  
is made to limp along.

The current RPM ports should be more than enough to sort out the other  
problems that MacPorts has with binary package (rpm) building - at the  
moment it looks like doing binary archives (tlz) would be a better  
alternative ?

--anders