Here is a collection of my thoughts on darwinports issues in no particular
order.  I'd like to point out that darwinports has a harder time with
packaging and distributing applications due to the fact that they are
an add-on.  Most packaging systems in open source systems rely on the
fact that there is one vendor, and they provide all the core components
of the system.  One consistent system with one set of consistent policies.
Darwinports doesn't have that luxury.  The OS vendor does not provide
a system which dp can hook into, and does not coordinate with DP in
any way.  There can be multiple inconsistent systems and policies in
place in the environment in which darwinports must function.  Often
times simply taking off the shelf solutions from other vendors may
only be a partial solution.  DP needs to choose carefully between
rolling their own, extending other people's solutions, and defining
certain problems to be beyond their scope.

- Use of system vs. dp provided libraries
If darwinports provides a library, it should always be used, and
the system provided library should never be used.  This is meant
to be a hard rule, not an opportunistic one.  For example, dp
provides zlib, there is a system zlib, and a port requires zlib.
If dp's zlib is not installed, it should be installed prior to
building the dependant port.
There are several reasons for this.  For one, there can be linking
problems if mixing and matching occur:
lib A is provided by the system and dp.
lib B links against lib A.
app C links against both lib B and lib A.
lib B is installed and links against the lib A provided by the system.
lib A is later installed via DP.
app C is then installed and links against lib B and lib A provided by DP.
We now have a problem where there are two different versions of lib A
being linked against for app C.

Another reason why always using DP provided libraries is important is
because then DP controls the update schedule.  DP cannot rely on Apple
for compatibility, consistency, or timely updates.  Apple has shown
in the past that compatibility may be sacrificed for a greater good.
ncurses is a painful reminder to us all.  Consistency is always in
jeopardy due to apple's updating process.  Libraries and executables
may be updated in software updates, but header files and other support
files only get updated in xcode updates if at all.  Even for someone
keeping on top of both system and xcode updates, the schedules are not
in sync.  System libraries and headers may be out of sync for months.
As for timely updates, something that may be critical for a dp linked
app, may not be critical for apple.  A new version of a dp port may
require an updated system lib, which apple cannot or will not provide.

- duplicated effort
Binary packages for darwinports have been a goal since the beginning.
However, the original goal for darwinports' packaging support was to
be packaging agnostic or to function without a packaging system as
it currently does.  This has resulted is massive duplicated efforts.
The key areas are archive mode, reciepts, and copying the destroot
into $prefix.
What needs to happen is the 'ports' side of darwinports needs to
stop as soon as the destroot is populated.  From there, build a
package.  The package manager is then responsible for ensuring a
consistent system.  Otherwise, darwinports will be reimplementing
a package manager internally, and have two (or more) separate code
paths for installing and ensuring consistency of bits on disk.

- pick a single packaging system
Darwinport's goal of being packaging agnostic (if no longer explicit,
it is still implicit with bitrotted hooks for rpm, dpkg, and others).
The reasons for this is being able to pass packaging system specific
information from the Portfile (the single source of information for
a port) to the packaging system.  By packaging specific information,
I mean things the packaging system cares about, but the build system
(the ports system) does not.  For instance, the apple packaging system
cares about things like whether or not the package requires administrative
privleges to install, a eula to agree to, whether the package requires
a reboot, etc.  Other package managers may care about runtime dependencies,
special treatment for specific files during upgrades/removals, etc.
The two alternatives to picking a single packaging system are to:
1) abandon all package specific information (or at least abandon the
ability to specify it in the Portfile)
2) require every port to fully implement package specific information
for every supported packaging system.
Otherwise, some ports will only work with some packaging systems,
and it will be a mess.  For support reasons, picking one and sticking
with it is best.

When the first elected (as opposed to appointed) portmgr was formed,
they decided on the Apple .pkg format.  I personally believe this
is a poor choice as it lacks so much of the functionality provided
by other systems, and provides so little in exchange.  However, this
was stated direction.

- Frameworks
I've written quite a bit on frameworks in a unix environment here:
http://www.opendarwin.org/~bbraun/frameworks.txt
Darwinports (afaik) has no explicit policy on frameworks.  There was
quite a lot of discussion a while ago on frameworks, and a truce was
called where dp will not actively frameworkify anything, although it
may end up installing a framework if that is what the upstream 
maintainer provides.  This is probably a reasonable policy, although
I do not believe all current ports obey it.

- Variants and Dependencies
First, let me qualify this as there are at least two types of necissary
dependencies: build dependencies and runtime dependencies.  It may turn
out that there are a lot more, depending on various other implementation
details.  However, I believe these are two fundamental ones you'll have
a hard time avoiding.  Currently, DP (sort of) implements just 
"dependencies", sort of a manually updated union of any sort of
dependencies.  build dependencies should be in the form of something
the packaging system can understand, to allow bidirectional communication
between the build system and the packaging system.  The build system,
when building something, will need to ask the packaging system to make
sure the build dependencies are installed.  It will then traverse the
dependency graph for each of those and either find a package (and it's
runtime dependencies) and install them, or will invoke the build 
system (which may call back to the package system for more build 
dependencies), to build a package which it requires to satisfy the
request but can't find a prebuild package for it.  Runtime dependencies
are only ever examined by the packaging system, although the build
system may be invoked to generate a package to satisfy them.

This symbiotic relationship between the packaging system and the
build system is not strictly necissary, although would be nice.
Fink takes the approach of the build system (fink) analyzes the
build dependencies and queries the packaging system (dpkg) to see 
what is available, then will either invoke the packaging system
to install what it already knows is available, or build the dependency
its self.  In other words, the build system can call the packaging 
system, but the packaging system can never call the build system.

Now, variants are another issue that can throw kinks in the system
as a whole.  Most packaging systems out there that handle dependencies,
use a name-version-revision approach.  There seem to be only a few
reasonable approaches to this problem:
1) avoid variants altogether
2) encode the variant in the name, which will require some tricky
dependency handling with either a way to say one package provides
the same thing as another package, or a way for packages to list
all the forms of a port they will work with (or a hybrid of the two).
3) a new system that takes variants into account, which would be
pushing the complexity from the naming/providing system above,
into the packaging system.

- Multiplatform
Back to othe first elected portmgr (jmpp, mww, olegb).  It was decided
darwinports was to be OSX/Darwin only, however other platform support
was left in, only to bitrot into uselessness.  This has resulted in
significant cruft, and confusion on the part of developers trying
to contribute.  Then, although Darwin support was never explicitly
dropped, no one tests on Darwin.  When this was pointed out, portmgr
stated it was unreasonable to expect people to test their ports
on Darwin, and it wasn't darwinport's to provide a darwin system 
for people to test on (rather, the claim was made it was the 
OpenDarwin Project's responsibility to provide it).  In any case,
Darwin was implicitly dropped at that point.  If DP is really going
to implement portmgr's direction, they would be well served to 
remove the non-OS X cruft and simplify the codebase.

- Simplification
At this point, we have decided on removing archive mode, reciepts,
installing the destroot to $prefix, multiple packaging system support,
and multiple platform support.  DP's codebase can be dramatically
simplified easing and accelerating development of features more in
line with it's end goals.

- Philosophy of support
Initially, there was a Jordan-driven philosophy of if something could
potentially work, don't prevent it.  For instance, if a portfile
was written on OS X 10.2, it might possibly work on Windows, so
let someone try.  I advocate a different approach: advertise only
what is known or at least asserted to work.  If a portfile is
written for OS X 10.2, flag it as only working there.  Do not
let someone get 10 deps deep in the build chain before letting
it blow up because that port was never supposed to work on their
environment in the first place.  Instead, let them know the action
they requested cannot be completed and why.  Don't let people waste
hours simply on the hope something might possibly work under some
undetermined set of conditions.
This approach would allow for a port to state what version of the
OS (since we're only talking OS X support at this point) it is
supposed to work with.  This can avoid the problems of people on
10.2 failing to build ports that were meant for 10.4.  Also, it
avoids the problem we have whenever there is a new release of
having half the ports tree work with the previous release because
their maintainers haven't updated yet, and half the ports tree 
work with the new version.  For any given system, half the ports
tree is unusable.

- ABI / Xcode issues
Currently, there is no acknowledgement or policy in dp of different
compilers and changes in ABI between compiler/Xcode versions.
This will be an even bigger problem with binary packages, unless
the entire repo is rebuilt whenever a piece of the toolchain changes,
and then every user will need to remove and reinstall their packages.
I am not aware of a packaging system that already has support for
this builtin.