Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Mart Raudsepp]

On K, 2017-12-20 at 17:28 -0600, Dale wrote:
> Grant Edwards wrote:
> > On 2017-12-18, Grant Edwards <grant.b.edwards@×××××.com> wrote:
> > > On 2017-12-18, John Blinka <john.blinka@×××××.com> wrote:
> > > > On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
> > > > <grant.b.edwards@×××××.com> wrote:
> > > >
> > > > > How do I skip grub and continue?
> > > > emerge --skipfirst --resume
> > [...]
> >
> > > Oddly, the failing package (grub:0) wasn't the first one: it was
> > > about
> > > 5-6 packags down the list.  So I used --exclude instead.  We'll
> > > see
> > > how far that gets...
> > It took a couple days, but after "resuming" the emerge three times,
> > it
> > finished.  The three failures were grub:0, matplotlib, and crrcsim.
> >
> > Each time the failed package was around 5th on the list when I did
> > a
> > resume.  And, each time emerge insisted on rebuilding gcc and glibc
> > first.  [I don't remember what else preceded the failed packages
> > when
> > I did the resumes.]
> >
> > I think I'll postpone upgrading to profile 17 on my "real work"
> > computers where I have a lot more packages installed.
> >
>
>
> I'm not sure why or what all this involves but there is a thread on
> -dev
> about a 17.1 profile coming at some point.  One may want to consider
> waiting to do to much for that.  Some of the messages make it seem to
> be
> a really large process to upgrade to it.  I'm hoping some or even
> most
> of it is just the devs testing things.  o_O
>
> Just a thought. 

It's about making /usr/lib not be a symlink to lib64 anymore on amd64.

I wouldn't wait for it, could get complicated and messy to do both at
once. If 17.1 pans out (or well, maybe "18.0" when going out of
experimental testing phase next year..), it won't need a full rebuild,
at most only things that have /usr/lib/ entries (instead of /usr/lib64
or /usr/lib32) in portage CONTENTS file in VDB to fix those things up
after the migration tool.

And I don't see anything overeager in --depclean. Maybe a dependency
was removed later, so with still default "--dynamic-deps y" you get
them removed now. If this breaks something, then there's an automagic
dep involved (which should have a bug report and be fixed), or some
changes done to some ebuild without proper revbump.
I think --with-bdeps toggling might let it remove build-time only deps,
though. I didn't observe that being used in the thread here in a way
that lets these build-time only deps get removed, for that to be it.