Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

[Sam James]

> On 3 Nov 2021, at 22:15, Joshua Kinard <kumba@g.o> wrote:
> Actually, it is possible to manage dependency errors like those.  It just
> takes a *lot* of elbow grease, and and long, long time time.  Especially if
> you have museum-grade hardware that these errors are happening on.
>
> For Perl, I've usually just uninstall everything under virtual/* first, then
> try to let it upgrade.  Sometimes that "unsticks" something in perl-core
> enough to let the upgrades apply, pulling back in any needed items from
> virtual/.  If that doesn't solve the problem enough to let emerge do an
> upgrade cycle, I'll try using just the @system target, or start yanking
> things out from perl-core/* one-by-one until emerge shuts up and does what
> it is told.

For what it's worth, you really really shouldn't need to do this.

Perl is great at consuming backtracking cycles (largely because
of all of the || ( ... .... ) deps in the virtuals) and cranking that
up helps a lot.

But something which we're not really clear enough on is that
users should genuinely never have to use emerge -C / --unmerge.

Trying just @system shouldn't be needed either and is in fact
likely to be more problematic:

https://wiki.gentoo.org/wiki/Project:Portage/FAQ#Why_is_there_a_dependency_conflict_when_I_attempt_to_upgrade_a_single_package.3F

> Also, *always* check for libperl-www being in the package list.  It's
> usually sucked in by way of dev-util/intltool and is responsible for ~35-40
> perl packages alone being pulled in.  If that's in the list, try
> uninstalling just that one, then run a depclean to remove all of its
> dependencies and then see if the upgrade will work.  If the upgrade tries to
> drag intltool or libperl-www back in, use --exclude to hold it out for later.
>

Aye, we fixed eudev to not need it anymore and there's an avahi
bug for the same I'll look at shortly.

> That all said, am I alone in thinking that the way Portage emits error
> messages about dependency resolution problems is extremely messy and
> border-line unreadable at times?  The current way it outputs depgraph errors
> feels like something I'd expect from a --debug switch.  We've got a
> reputation for being playful and colorful on the command line with our
> tooling, so I would wonder if that depgraph output couldn't be made to
> look....nicer?
>

Yeah, I think one of our biggest weaknesses is that there's
usually a LOT of output and figuring out what matters isn't easy.

A good rule of thumb is that the "most fatal" error is _usually_
at the bottom but this isn't always true.

Best,
sam