On K, 2017-12-20 at 17:28 -0600, Dale wrote: > Grant Edwards wrote: > > On 2017-12-18, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > > > On 2017-12-18, John Blinka <john.bli...@gmail.com> wrote: > > > > On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards > > > > <grant.b.edwa...@gmail.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.
