Installed ports should not change their installation location unless
they are upgraded.
When I did the /Applications/DarwinPorts -> /Applications/MacPorts I
did not flag any port as revised since I did not see this as a
substantive change and thought that already installed ports should be
left where they were and that upgraded or newly installed ports
should go into the new location.
So the original behavior of python24 going into /Applications/
DarwinPorts was correct as was the behavior of Abiword going into /
Applications/MacPorts. It was also correct that you should not have
seen python24 move into MacPorts unless you forced a rebuild as you did.
On 14 Feb 2007, at 05:21, Christian Voelker wrote:
Hello,
Essentially you are right, but ...
Am 13.02.2007 um 23:08 schrieb Ryan Schmidt:
Perhaps it has been done and you just haven't upgraded
that software since then?
As I wrote, I have installed macports initially
one month ago and have done several syncs and a
selfupdate since then. Furthermore, I found the
Portfile for the port in question, python24 not
to be altered since spring last year as stated
in the first lines. Also, python24 was not lis-
ted when running "port list outdated". As such,
I felt on the safe side to post to the list with-
out forcing an upgrade first.
After your advice, I took time to upgrade, which
did not take effect until I forced it - it was
not outdated. During build, I found the directory
/Applications/DarwinPorts already removed and the
associated helper Apps were placed into /Applica-
tions/MacPorts afterwords as intended.
The "but" in my top statement refers to the fact,
that the files *were* installed in /Applications/
DarwinPorts initially only one month ago. Natural-
ly, I dont know the exact order of installation
any more, but I guess that I installed python24
as a dependency right after unpacking an instal-
ling the macports .tar.bz2 file.
I dont know, whether this file already contains
an outdated ports tree to start with or whatever,
but I guess that there is still a reference inside
that causes the /Applications/DarwinPorts to be
used. I dont know any other reason why it should
have happened. As such, I suggest to update these
files. The file that I used was:
http://svn.macports.org/repository/macports/downloads/
DarwinPorts-1.3.2/DarwinPorts-1.3.2-archive.tar.bz2
The only occurrence of the searchstring "/Applica-
tions" I found therein was at line 174 of
http://svn.macports.org/repository/macports/trunk/base/src/port1.0/
resources/group/xcode-1.0.tcl
This file *currently* contains the proper value
http://svn.macports.org/repository/macports/trunk/base/src/port1.0/
resources/group/xcode-1.0.tcl
The change in question was at 02/10/07 08:01:38,
Revision 21852 and the comment was: /Applications/
DarwinPorts to /Applications/MacPorts everywhere
http://trac.macports.org/projects/macports/log/trunk/base/src/
port1.0/resources/group/xcode-1.0.tcl
The revision 19070, included with 1.3.2 was from
08/09/06 20:14:15 represents a previous state and
carries the following commit message: This commit
was manufactured by cvs2svn to create tag 'release_1_3_2'.
http://trac.macports.org/projects/macports/log/tags/
I hope, this helps.
Bye, Christian
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
Randall Wood
[EMAIL PROTECTED]
"The rules are simple: The ball is round. The game lasts 90 minutes.
All the
rest is just philosophy."
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
