On 24/08/2015 15:17, Alan Mackenzie wrote: > Hello, Harry, > > Long time, no see! > > On Sun, Aug 23, 2015 at 10:19:42PM -0400, Harry Putnam wrote: >> My gentoo OS is running on Openindiana (solaris) inside oracle's vbox. > >> It's been left setting for at least 4-5 months maybe a couple more. > >> After eix-sync, attempting an `emerge vuND world' comes up with so >> many blocks, use flag changes and a variety of other bad news in >> such proliferation... I'm thinking better to install from scratch with >> latest ISO. > > I know the feeling. When the same thing happened to me (my system got > into a mess because I was running XFCE which was too dependent on > gnome-2; when gnome-3 became stable, the demons of hades were let > loose, and I tried a couple of times, half-heartedly, to update), I told > myself to stop and think. > > I could spend days fighting with use flags and conflicts, or I could > spend a few days reinstalling. In the end I reinstalled (using the old > system (rather than an ISO image) to do the initial stages. It took me > about a week, compared with about a month the first time I seriously > installed Gentoo. "Installation" here means getting everything up and > running, including X with destop manager, printing, sound, email server > and client, ....
At first glance it does look like maybe a reinstall would be better. But in this case, that's not true. Looking over the list of packages to be updated, there are 3 general classes of things: 1. Regular updates 2. A whole whack of rebuilds 3. A perl upgrade from 5.20 to 5.22 #1 is routine. Press enter, and make does it's thing #2 looks scary, but in the old days we'd have to do the updates then let revdep-rebuild catch the inconsistencies, and rebuild those. Modern portage has some magic code to fold everything into the main emerge world step. So just press Enter and make does it's thing #3 can be very confusing. With 5.22, upstream moved many Perl packages into the core Perl codebase, so all such installed packages (and all of us have many of them) need to uninstall perl-core/<package> and replace it with virtual/perl-<package>. Portage normally deals with this transparently, but the output can be a little too verbose sometimes, and takes some decent brainpower to figure out what is really going on. There's also some blockers in that list ([blocks b ]), but they are all soft (lower case b) so portage should take those in it's stride and just fix it with no intervention. Harry's real problem as many have noted is that his gcc config is not valid. But, portage can't tell him that. It started the merge, and handed control over to the next app, which portage can't make sense of as it all happened outside portage's control. Result: a wall of text on the screen, right after the wall of text of 195 things to be rebuilt and a huge list of stuff causing other stuff to be needed to be rebuilt! I suppose those ebuilds that are sensitive to gcc versions could have a check built in to check the version before starting and then print a sane error message that portage CAN control and make sense of. Either way, "gcc-config -l" is what Harry needs to run first, and make his default compiler 4.7 or later. With that out of the way, emerge should proceed normally apart from taking a while to get through it. He might have perl issues afterwards and need to run perl-cleaner. The real problem is how do I know all this, and Harry did spot it? Well, building a source distro comes in at a much lower level than a binary one, and it does take a good large dose of experience, knowledge and plain old luck to figure out what is really going on. These days portage is very good at doing the right thing (it still sucks at a human level in it's output...) and today Harry just got really unlucky. So yeah, reinstall is probably not the better option here. -- Alan McKinnon alan.mckin...@gmail.com
