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