port install efficiency issue

[Darren Weber]

2009/3/22 Frank J. R. Hanstick <trog24 at comcast.net>

> Hello,
> Wouldn't it be better and faster to do the check at request time rather
> than wait until everything has been done and then request if an update is
> wanted rather than an install?
> Frank
>


Yes, sounds reasonable.

Also, my apologies!  Macports is great and so much so that I like to
contribute to it whenever I can!
http://trac.macports.org/wiki/dweber

Yes, fink has some issues too!  Nevertheless, I have used Debian (mostly
Ubuntu) for a few years and I've lived to appreciate that system (despite
some initial headaches with stable, unstable, ouch-bleeding on the testing
stuff).  For the most part, I think the dependency resolution and the
upgrade process is amazing.  I am very pleased to see this system available
for OSX and I do hope it lives on in all it's wonder.

I've made a move over to OSX for a new job and I guessed that macports would
be the right way to go, basically because I guessed it would be a BSD system
(or darwinports system) and I assumed that would be totally rock solid and
efficient because it's been around for decades (even in those days of
scheduled compilation).  I'm a novice when it comes to BSD and OSX, so this
is a great learning opportunity for me (even if I lose it sometimes).

On balance, I'm both impressed and disappointed with the complexity of the
macports system to date.  For example, dependency resolution needs a lot of
work during upgrades, binary distributions are a great idea in the making
(perhaps forever in the making), and the whole issue of dependency on
variants is a massive conference debate.  I've certainly come across these
issues and tried to submit reasonable trac suggestions for enhancements,
etc. on a couple of ports.  My main issue seems to be in getting a few ports
with a lot of dependencies to cooperate, esp. with regard to variants (eg,
Qt, Postgresql, MySQL, VTK, etc.).  I do think that package maintainers
should think very carefully about their default variants and try to provide
as many options as possible - that seems to be the way with Debian
packages.  It seems to me that Debian uses a different set of packages for
every major release, whereas macports tries to accommodate all the OSX
flavours into every Portfile.  Perhaps one way to reduce the confusion is to
create branches in the port tree for each major OSX release and platform
(PowerPC, intel, iphone; what's next?).  Perhaps some of these things are
rightly compiler variants or something, but how much easier it might be if
you just choose the right branch for your platform to work on?  I guess that
raises the problem of where to edit the Portfile and management of multiple
files in different branches - ouch.  I don't know how that's done in Debian.

Nevertheless, I will push on with macports and I'm trying to do my part to
both support and encourage open-source systems.  That's the bigger picture
here and I'm very sorry that my frustration on this thread raised a
relatively minor quibble about distribution systems.  Unfortnately, my
comments were emotional, but that's how it is sometimes and that's when you
really feel that there has to be a better way.  Patience is a virtue, I just
lose it sometimes.  Thankyou all for your understanding and, moreover, for
the many reasonable suggestions to make macports even better.

Take care, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090322/3e2acd46/attachment.html>