Re: [gentoo-user] emerge world looking grim

[Alan McKinnon]

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.mckinnon@×××××.com