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

On Fri, Sep 06, 2013 at 05:59:42PM +0200, O. Hartmann wrote:
> On Fri, 06 Sep 2013 17:35:27 +0200
> Guido Falsi <madpilot_at_FreeBSD.org> wrote:
> 
> > 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?
> 
> How should I when I already within the procedure of updating? I
> followed the minimalistic instruction in UPDATING.
> 
> > 
> > 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.
> 
> This is the worst suggestion ever. People do work with their FreeBSD
> boxes, even when they run cutting edge OS versions. Deleting and
> installing around 1000 ports on an average desktop workstation isn't
> funny! That is, why I do updates.
> 
> Every thing else would degrade this system into the state of an
> annoying toy operating system and that is definitely not what I believe
> others intend it to be.
> 
> The time of M$ DOS and Windows 95 and their strategy "if something goes
> wrong, install the whole OS new" is gone and has never been for people
> having choosen UNIX over the M$ crap and the silly dirty strategy 
> > 
> 

We are just trying to catch up the activation of iconv in base which is
resulting a complete mess in ports.

We do understand how problematic this can be for you and We are sorry about
that.

In you special use case, I would strongly recommand you to change the way you
are managing you setup to change it into a a package building server and when
everything is ok deploy you packages on all your serveurs/desktops.

Poudriere can do that fairly easily, you can prepare different package building
destination (that fits all your need, with special patches, special options in
src.conf etc).

That way you can follow head, and not get annoyed by such changes.

In you case what I would do is:
$ Rebuild world WITHOUT_ICONV
$ reinstall libiconv
$ portmaster all that depends on libiconv

Here you got back to the old situation.

Now on a decicated machie I machine I would install poudriere, create a jail
matching the server specification (without libiconv)
build all my packages on it

If everything is ok.

Rebuild my server WITH_ICONV

Make my server use the built repository
$ pkg upgrade

(This should catch up everything)

and you system is clean and usable.

Next time you have to upgrade first upgrade the package building jail and
packages, if this is ok, then upgrade world/kernel on your server, pkg upgrade
and you are done, updating the box (in term of packages) will cost you a couple
of minutes, you will be sure that everything has properly build.

regards,
Bapt