On Nov 20, 2007, at 4:02 AM, Anders F Björklund wrote:
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 ?
No, not at all! The contents of all our documentation will eventually be "sorta" hands off rather than *completely* hands off because we want to keep a limited set of eyes and hands working on it, so that the overall result is more coherent than if just anyone who happens to walk by tosses his/her bit of information in it, which leads to disorganization and unreadability. But that by no means implies that others can't contribute, make suggestions, submit patches, discuss with Mark || Simon || Maun Suang, etc. Everyone should feel free to do so, please! Our guide and man pages are in this "sorta hands off state" 'cause they are already in hands of our writers, but docs like README, HACKING and others aren't yet, so feel free to claim it your own if you intend to ;-) As stated previously, we do intend for all those to eventually end up in the guide and therefore in this "sorta hands off" mode, but that's still in the future.
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#R...
I know what the file is about... I was wondering if you had a draft for it ;-) Not a terrible thing if you don't, though, wont stop 1.6 ;-)
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.
I'm sorry, I didn't follow that comment. Mind elaborating? In any case, can you please take a look at what Ryan Maun Suang and I discussed on that ticket? A *.pkg/Contents/Resources/VolumeCheck script parsing the output of sw_vers(1) might do the trick for us, but you've been working on the pkg targets lately so you're probably much more fit than any of us to tell how we could achieve our goal on Tiger/ Leopard with traditional/flat pkg formats. Pretty please....? ;-)
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.
Ack! Will advise Mark on that one when he's available again.
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!
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 ?
First comes building logging support into MacPorts (my nex goal & top priority after the new website and 1.6) and then constructing our automated & distributed builds infrastructure (build farms, chroots, trace mode, etc) to actually have something to package, so I wouldn't worry too much just yet about fleshing out rpm issues in MacPorts at the moment. I more than love the effort and work you're putting into packaging and how you're pushing us forward on this front, trust me (!!); but, sadly, whatever packaging effort we put together is going to be pretty lousy without support for automated builds & logging.
--anders
Regards,... -jmpp