libiconv problems after urxvt upgrade

[Joerg van den Hoff]

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 at 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 at 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 at 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 at 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