AFFECTS: 10-CURRENT users with any port depending on converters/libiconv

[Guido Falsi]

On 09/06/13 17:04, O. Hartmann wrote:

> Using portmaster, I'm higly adviced to use option -f, otherwise every
> second port I try to update gets interrupted due to missing
> libiconv.so.3. It is impossible to update a system unattended and this
> is a mess with 200 or even 680 ports to be updated. A waste of time.
>
> Some ports still rely on methusalem gcc 4.6. But gcc 4.6.3 relies on
> some gnuish tools in the port and the compilation fails if those
> prerequisits aren't updated first. The description I found
> in /usr/ports/UPDATING is quick and dirty - too dirty for being
> useful, in my opinion. Did the maintainer ever tried this command
> sequence on a "used" machine and not in a clean vbox environment?


I have tested it on my two machines at home. Both "lived" ones. On one I 
had problems, but I did not follow that procedure exactly.

On the laptop everything went definitely smoother.

> There must be a description of a fallback in UPDATING! I took the
> whole day to update on one machine less than the half of the installed
> ports and huge ports like libreoffice are still dropping out of the
> build and I restart after fixed the missing port that relies on being
> recompiled. I hope that reinstalling converters/libiconv will give me
> X11 back on my boxes! I can not stay with them 48 hours non stop until
> they have completed the messy update.

The first backup things that comes to mind is, one can always reinstall 
libiconv (removing IGNORE), that should allow old binaries to run. I 
don't suggest updating the other ports while libiconv is installed 
though, since the include files will conflict and ports could link to 
the por5ts libiconv instead of the base one.

As I told AN, preserving libiconv.so in /usr/local/lib/compat/pkg and 
then removing the package could help, by allowing the machine to work in 
a "mixed world". Can you try that?

The biggest problem is usually libtool, pulling in old .la files still 
referencing the non existing libiconv.la file. I don't know of any 
solution to that. I had to resort to manually listing offending la files 
and recompiling the owning package. Not optimal :(

I am willing to add further information to the UPDATING entry, but I 
need people with different scenarios to test and report the success of 
the strategies.

Obviously the last resort strategy is deinstalling all ports and 
reinstalling them, which I agree is terrible.

-- 
Guido Falsi <madpilot at FreeBSD.org>