Existing users, 
I really don't use the "aquafied" version. X11 works for me, even with its quirks. But, mostly, I've begun to just use the Terminal. One thing that should be fixed, if not already, is:
When you initiate any download with dependencies, via Terminal or X11 (don't know about Aqua) versions, the "process" should NOT automatically download ANY dependencies that match System or /usr/local "current" executables/librairies, etc. When upgrading (ONLY!) an already installed port, you can use the "-n" option ["don't follow dependencies in upgrade (only for upgrading)"], per the port man-page.
PortAuthority
Aqua-native GUI for MacPorts.
Version: 3.0
Why?
Feedback Type: Commentary
Contributed by: dhsanto Tuesday, November 14 2006 @ 10:16 AM PST
Product Platform: MacOSX
Used Product For: Over One Year
Comments
Why? - dhsanto
When I do a manual/normal install (config/make/install), the "configure" step prints "checking" messages in Terminal. Occasionally, I see something like "resolv.h found, but, can not be compiled..." (the dependency of an installed file that is used in the config & build of the target file). Obviously, the config-process has a way of checking whether or not it can utilize a particular (header-)file. Couldn't something like this be implemented? Say, a little version-test to see if the dep-file is the most current (and CAN be used) and during/after building the "desired" file(s), an actual use-of-the-already-installed-file test? Besides, I would think that if a build would fail, there could then be a warning like "Build Failed! You MUST let PA Get a Newer Version of name-of-file."After getting several non-compileable resolv.h warnings about missing or incorrect header-files, I looked into the include headers in that file, found and corrected the problem (after researching it, a lot, first). No more resolv.h issues! And, that file is installed with OSX and/or the Developer Tools.
Wednesday, November 15 2006 @ 01:43 PM PST
Why? - Kevin_Walzer_897
I suggest you file a bug report/feature request at macports.org on this issue. It's not something that PortAuthority can control in any way; it's internal to the way MacPorts is designed.Friday, December 01 2006 @ 01:09 PM PST
Why? - Kevin_Walzer_897
MacPorts, by design, builds its own stuff in a sandbox (/opt/local by default). There's way too much potential for conflict if MacPorts looked in /usr/local or elsewhere.Reply to This
Tuesday, November 14 2006 @ 11:35 AM PST