On Nov 29, 2008, at 12:44, Joshua Root wrote:
Frank Hanstick wrote:
I did the deactivate and independent install which worked;
but, the
question remains as to why was cyrus-sasl reactivated before
upgrading
when deactivated before hand.
What I am referring to as a script is the procedure by which
MacPorts upgrades ports which may not literally be a script; but, a
script in the sense that a strict set of procedural steps are
followed.
I notice in the upgrading process, that deactivation of an
installed
module occurs immediately after the building. Could the
deactivation be
changed to the point where the needed upgrade is made, which I
assume is
before the build, and reactivated afterwards whether or not an
upgraded
installation occurred? This seems like a simple change to the
procedural steps by someone who knows the insides of MacPorts.
A change along those lines is probably possible, but I would not
characterise it as simple.
To upgrade a port, MacPorts currently runs the phases in this order:
fetch
checksum
extract
patch
configure
build
destroot
install
deactivate
activate
clean
I may have missed a phase or two but that's basically it. MacPorts
gets, verifies and compiles the new version of the software, stages
it into the destroot, copies it into the software directory, and just
before making the hardlinks in ${prefix} to activate it, it first
removes the old hardlinks in ${prefix} belonging to the old version.
The reason for this order is so that the old version remains
available to any other processes on your machine for as long as
possible.
However, cyrus-sasl2 is in the small minority of software that does
not build correctly when another version of cyrus-sasl2 is activated.
This is a bug in cyrus-sasl2 which the authors of that software have
not fixed, so all we can do for now is offer workarounds.
To fix it in MacPorts base would require changing the order of the
phases so that deactivate comes before configure. This would mean
that for the entire duration of configure, build, destroot and
install, the old version of the software would not be available.
This might be ok for cyrus-sasl2 which probably builds pretty quickly
even on slow machines. But consider the larger ports. If I want to
upgrade gcc43 or ghc on my Power Mac, it will take about a day to
compile. Now it's possible that some time during that day I will also
want to make use of gcc43 or ghc. With your proposed change, I would
no longer be able to do that because it would have already been
deactivated.
A better solution is to work with the authors of cyrus-sasl2 to get
their software to compile correctly even if another version is
already available on the system.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
