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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
