ryan, thanks a lot for bothering. I really appreciate this. On Fri, Mar 14, 2008 at 06:39:20AM -0500, Ryan Schmidt wrote:
On Mar 13, 2008, at 06:11, Joerg van den Hoff wrote:
during upgrade from urxvt8.7 to the current version I got the error message
===================================CUT================================ ======== Portfile changed since last build; discarding previous state. ---> Fetching libiconv ---> Verifying checksum(s) for libiconv ---> Extracting libiconv ---> Applying patches to libiconv ---> Configuring libiconv ---> Building libiconv with target all ---> Staging libiconv into destroot ---> Packaging tgz archive for libiconv 1.12_0+darwin_8 ---> Deactivating libiconv 1.11_0 Error: Deactivating libiconv 1.11_0 failed: Active version of libiconv is not 1.11_0 but 1.11_0+darwin_8. ===================================CUT================================ ========
Peculiar...
after which install proceded (apparently successful).
I don't know why MacPorts proceeds when it encounters an error activating a port. This only leads to further errors down the road, as you've seen:
deserves this an "official" bug report (I was hoping a bit the ml might suffice)?
trying to start `urxvt' now throws the error: ===================================CUT================================ ======== dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib Referenced from: /opt/local/lib/libXft.2.dylib Reason: Incompatible library version: libXft.2.dylib requires version 7.0.0 or later, but libiconv.2.dylib provides version 5.0.0 Trace/BPT trap ===================================CUT================================ ========
No libiconv is active, because of the earlier error, so ports that require libiconv now explode.
trying a
`sudo port deactivate libiconv@1.11_0+darwin_8'
yielded ===================================CUT================================ ======== Error: port deactivate failed: Registry error: libiconv not registered as installed & active. ===================================CUT================================ ======== which seems inconsistent with the error message during urxvt install.
Agreed. That seems inconsistent. Not sure how you got into this state.
neither am I. I'm definitely _not_ tinkering with the system. rather I try to upgrade by and then relevant packages and go on with my work.
after a `sudo port activate libiconv@1.12' now everything seems to work,
Great!
but the above messages seems to hint at some grade of corruption of the internal state of port. is this the case? can I sanitize/check it somehow without purging everything?
What does "port installed libiconv" show now?
this: The following ports are currently installed: libiconv @1.10_1+darwin_8 libiconv @1.11_0+darwin_8 libiconv @1.12_0+darwin_8 (active) libiconv @1.9.2_1
I also notice that many packages appear both with `port list active' _and_ `port list inactive'. how can this be?
"port list" does not do what you think it does. "port list" does the following: for each port, display the current version (not the installed version).
You probably would rather use "port installed active" and "port installed inactive".
thanks for this clarification. I read the manpage again: this behaviour is far from obvious from the manpage, since there "installed" and "active" are both listed as pseudo-portnames which should imply that 'port list active' should do what I expected. also "port installed" (or "port installed active") works while "port active" does not. should not the manpage be modified to make this point clear?
and a last question: the "active" ports are the only one in use
Yes.
or are "inactive" ones (especially libs) secretly used by other ports?
No, inactive ports are not used at all.
I noted that a tentative
`sudo port uninstall libiconv@1.11_0+darwin_8'
showed me lots of ports depending on it which would need prior uninstall.
The message shown by MacPorts is misleading. The message says "Unable to uninstall libiconv 1.11_0+darwin_8, the following ports depend on it" but what the message should say is "Unable to uninstall libiconv, the following ports depend on it" (in other words it should not list the version or variants). Since you already have a newer version of libiconv installed, it's perfectly fine to remove the older version. MacPorts just doesn't know any better. Educate it by using "-f" when uninstalling ports in such situations:
ah. maybe I manage to remember this in the future.
sudo port -f uninstall libiconv@1.11_0+darwin_8
I understand that different versions of libs are needed at the same time
That's not how MacPorts works. Only one version of a library can be used at a time. If multiple versions of a library are needed at the same time, multiple separate ports must be created. See for example apr and apr0, db41 thru db46, and many other examples.
please, could you clarify this a bit? does this not still mean that, e.g. apr requires/installs, say libtmp1.1, and apr0 libtmp1.2 so that both need to be there and are used "at the same time" (meaning when apr or apr0 are started)? whether this is necessitated by two variants of an application (say apr) or by uncorrelated apps seems not to make a difference. so, this is still not clear to me: I would expect that some ports rely on a certain version of a lib, others (e.g. more up-to-date ones) need different versions. surely not all available ports always are in a state that they use the same library versions? and even if so, would not otherwise a single upgrade of a single package (inclduing some lib update) lead to necessity of upgrading virtually _everything_ else which needs that library? (i'm not offended if I get the "read the manual" message :-))
but why, then, is one declared "active" the others "inactive"?
When you "sudo port upgrade foo", the old version is deactivated and the new version is activated. If you don't want the old version anymore, you can then uninstall the old version:
sudo port uninstall foo @1.2.3
If you want MacPorts to automatically uninstall the old version during the upgrade, use the "-u" flag:
sudo port -u upgrade foo
This will fail if any port depends on foo. In that case you must also force it. But the force flag also causes MacPorts to rebuild all dependencies, possibly multiple times, which you don't want. So if you want to force an upgrade, you should also always use the nonrecursive flag:
sudo port -nfu upgrade foo
so in short what's the difference between "active" and "inactive", especially for libs?
Inactive ports are not used. They're just there so that you can activate them again, should you choose to do so (after deactivating the version that you currently have active.) If you don't want to reactivate old versions, you can uninstall them to reclaim the disk space.
thanks a lot for getting most of my questions answered. joerg