>From: Mitch D. futurehyp...@gmail.com<mailto:futurehyp...@gmail.com> >Sent: Tuesday, June 13, 2023 9:36 AM >To: gentoo-user@lists.gentoo.org<mailto:gentoo-user@lists.gentoo.org> >Subject: Re: [gentoo-user] Re: Can't upgrade portage or update/install ebuilds > >On Tue, Jun 13, 2023 at 10:38 AM Grant Edwards >grant.b.edwa...@gmail.com<mailto:grant.b.edwa...@gmail.com> wrote: >On 2023-06-12, Wol antli...@youngman.org.uk<mailto:antli...@youngman.org.uk> >wrote: >> On 09/06/2023 21:16, Grant Edwards wrote: >>> On 2023-06-09, Daniel Pielmeier bil...@gentoo.org<mailto:bil...@gentoo.org> >>> wrote: >>> >>>> If it is only about gemato then temporary disable the rsync-verify flag >>>> which pulls it in. >>>> >>>> # USE="-rsync-verify" emerge sys-apps/portage >>> >>> The problem I ran into is that you never know how many issues there >>> are standing in the way of upgrading. The one time I decided to muscle >>> my way through updating an "obsolete" Gentoo install, [...] >>> >>> You do learn alot about how portage/emerge works... >>> >> Learning that is a good idea maybe :-) >> >> But last time I had a well-out-of-date system, it was a long and >> messy process ... >> >> What I did was, every time portage said "giving up" or "conflict found" >> or whatever, I just took a note of as many of the packages I could >> remember that portage said it could emerge, and then manually updated >> them "emerge --update --one-shot". >> >> And any conflicts, if I dared, I simply deleted then "emerge -C --one-shot". > >IIRC, at one point Python was one of those problems, and I stupidly >removed Python before realizing what that meant... > >Hilarity ensued. > >Removing/skipping as many of the non-essential "big" packages and >their dependancies and getting the base system updated is indeed the >best way to go. > >I second this approach. When rescuing a Gentoo system, my first step would be >to deselect any and every non-critical package from @world, then try to get >@system updated through any means necessary. In the past, I've removed >packages instead of deselecting them, but I've had cases where depclean >refused to do anything because there were already dependency problems, and >sometimes it's hard to know what's safe to unmerge with "-C". > I have noticed that doing a --unmerge on virtual/* clears away whole sections of conflicts in a lot of cases.
Doing the same on dev-perl/* is a decent trick too if it's snarled enough that perl-cleaner runs into conflicts. But sometimes perl dependencies aren't correctly spelled out, so you may have to reinstall some of it by hand in some cases. And you'd be surprised how many “hard” dependency version requirements are “softer” than expected. Using the "ebuild" tool to force it to "just do what it's told" and install the new version, and then "emerge -e @world" at the end of it all to clean up any mess uses a lot of machine time, but it can save a lot of human time. LMP
