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 <madpi...@freebsd.org>
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
