On Mar 14, 2008, at 07:38, Joerg van den Hoff wrote:
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)?
All bugs deserve a bug report in our issue tracker. :) I'm just not sure how to report this. I've seen it before, but I forget how it happened to be exactly. And you don't know how it happened to you either. Without a reproduction recipe, it'll be hard to fix. But it should still be filed. I tried to search just now (summary contains "activat", component = base) and didn't find it.
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
Looks ok to me. You can force-uninstall those older inactive versions if you want since nothing is using them.
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.
No... because "port list" does not do what you expected. Read the description of "port list" in the manpage: list If no argument is given, display a list of the the latest version of all available ports. If portname(s) are given as arguments, display a list of the latest version of each port. (I just noticed "the the" and fixed it in r35030.) So "port list active" lists the latest version of each active port, *not* the installed version of each active port. For example, if you deactivate libiconv @1.12_0+darwin_8 and then activate libiconv @1.11_0+darwin_8, "port list active" (or "port list libiconv") will still show "libiconv @1.12 textproc/ libiconv" because 1.12 is the latest version of that port.
also "port installed" (or "port installed active") works while "port active" does not. should not the manpage be modified to make this point clear?
"installed" is both a command (e.g. "port installed" -- show information about installed ports (by default, show information about all installed ports, but you can specify a subset if you want, e.g. "port installed libiconv")) and a pseudo-portname ("port info -- maintainer installed" -- show the maintainer of each installed port). "active" is only a pseudo-portname. It is not a command. Do you have a specific suggestion about what should be changed? A particular passage that is confusing, or a specific sentence you'd like to have added? Note that I believe the manpages have been rewritten since 1.6.0. That is, they used to be standalone manpages, but with the recent effort to write the web-based MacPorts guide, I believe the manpages have also been rewritten and reformatted in the same docbook style, though at the time MacPorts 1.6.0 was released there were some problems actually generating the manpages from the docbook sources so the old manpages were left in. I'm not sure if that situation has changed since then.
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.
I'll try to clarify, with the APR example. APR is the Apache Portable Runtime, a library used by the Apache web server, Subversion, and other software that wants to run on multiple operating systems without having to write lots of OS-specific code. OS-specific code is encapsulated inside APR. We have two ports for Apache 2: apache2, which installs Apache 2.2.x, and apache20, which installs Apache 2.0.x. Most people will want the latest version and so they will choose apache2. Some people may want to use pre-compiled modules designed for Apache 2.0.x which won't work with Apache 2.2.x, therefore they will choose apache20. Apache 2.2.x requires APR 1.2.x and does not work with earlier versions. Apache 2.0.x requires APR 0.9.x and does not work with later versions. Back in 2005, the apr port installed APR 0.9.x. But then in December 2005, APR 1.2.x was released and the apr port was updated to that version. You cannot ask MacPorts to install an older version of a port. You can only install the current version of a port. Therefore, we need separate ports apr (provides APR 1.2.x) and apr0 (provides APR 0.9.x) so that ports that want the latest version (like apache2) can use apr, and ports that want the older 0.9.x version (like apache20) can use that version. Back to libiconv: there is only one libiconv port, so your only option is to install the latest version of libiconv. If there were a port that required an older version of libiconv in order to run, we would have to make a second libiconv port for that older version of the libiconv software.
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?
In MacPorts, there is no way to specify that a port depends on a certain version of another port. It is only possible to specify that a port depends on another port.
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 :-))
For most library updates, the library is a drop-in replacement for the old library. Software that linked with and worked with the old library will continue to work with the new library. But consider gettext, the GNU internationalization library used by many many other ports. When gettext was updated from 0.14.x to 0.15.x, the library changed in a binary-incompatible way so the library version was increased, which caused all other ports to break until they were rebuilt. See the problem hotlist: http://trac.macosforge.org/projects/macports/wiki/ ProblemHotlist#a2.Aportfailedtobuildupgradeorrunwithamessagereferringtol ibintl.3.dylib This may not be super, but it is the state of MacPorts at this time.
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.