libiconv problems after urxvt upgrade

[Ryan Schmidt]

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

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

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.