> On 3 Nov 2021, at 22:15, Joshua Kinard <ku...@gentoo.org> 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
signature.asc
Description: Message signed with OpenPGP
