port install efficiency issue

[Ryan Schmidt]

On Mar 21, 2009, at 22:10, Darren Weber wrote:

> What is up with port?  It just ran for about 15 mins to build a  
> package that is already installed.  If I were to work on the same  
> damn thing, repeating it all day, day after day, I would get the  
> sack pretty quickly.  Just think of the useless load on the network  
> and the servers for all those futile downloads, etc.  So tell me,  
> why shouldn't I switch to fink?  At least Debian has a decent  
> package management system, geez!
>
> $ sudo port install gettext
> --->  Fetching gettext
> --->  Verifying checksum(s) for gettext
> --->  Extracting gettext
> --->  Applying patches to gettext
> --->  Configuring gettext
> --->  Building gettext
> --->  Staging gettext into destroot
> --->  Installing gettext @0.17_4
> Error: Target org.macports.install returned: Registry error:  
> gettext @0.17_4 already registered as installed.  Please uninstall  
> it first.
> Error: Status 1 encountered during processing.


We should keep our comments constructive. I'd like to minimize  
disparaging remarks about MacPorts coming from macports.org email  
addresses.

MacPorts certainly has room for improvement in many areas. But I  
think it's unfair to say it's not a decent package management system.  
Over the many years I've used it so far, it has saved me from having  
to figure out how to compile many packages, so in that regard it  
succeeds.

Regarding futile downloads and wasted resources, in this case you'll  
notice (from the absence of a line telling you what server it  
downloaded from) that it used an existing distfile already on your  
machine. No network bandwidth or server resources were used. Agreed,  
client CPU time was wasted. I would like to minimize client CPU  
usage, and we could make great advances there by finally distributing  
binaries instead of source and compilation recipes. Hopefully that  
will eventually occur.

With MacPorts 1.7.0 I do see the same issue you describe --  
sometimes. I'm don't know under what circumstances it happens. What  
*should* happen is the following:

$ port install zlib
--->  Fetching zlib
--->  Verifying checksum(s) for zlib
--->  Extracting zlib
--->  Applying patches to zlib
--->  Configuring zlib
--->  Building zlib
--->  Staging zlib into destroot
--->  Installing zlib @1.2.3_2
--->  Activating zlib @1.2.3_2
--->  Cleaning zlib
$ port install zlib
Skipping org.macports.activate (zlib ) since this port is already active
--->  Cleaning zlib
$

There are valid reasons for wanting to rebuild a port that's already  
installed. But it's probably reasonable to require the use of the -f  
flag in those situations. And I believe that's what is supposed to be  
implemented. But there appears to be a bug somewhere. I don't know if  
a ticket is already filed about this.