Summary: | sys-apps/portage-2.1.4.5: emerge --depclean fails with Dependencies could not be completely resolved | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Pacho Ramos <pacho> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | IN_PROGRESS --- | ||
Severity: | normal | CC: | bkohler, esigra, m27315, Manfred.Knick, sam |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 144480, 155723 |
Description
Pacho Ramos
2008-11-21 18:06:20 UTC
I(In reply to comment #0) > Just after running succesfully "emerge -avuDN world", emerge -a --depclean > fails with the following error: > Calculating dependencies... done! > > Dependencies could not be completely resolved due to > the following required packages not being installed: > > virtual/perl-ExtUtils-CBuilder required by perl-core/File-Spec-3.25 > > Have you forgotten to run `emerge --update --newuse --deep world` prior to > depclean? It may be necessary to manually uninstall packages that no longer > exist in the portage tree since it may not be possible to satisfy their > dependencies. Also, be aware of the --with-bdeps option that is documented > in `man emerge`. A likely explanation is that the perl-core/File-Spec-3.25 dependencies were changed sometime after you had installed it, and the update command that you used didn't pull in the new dependencies they were build-time only and you hadn't specified --with-bdeps=y. In case you're wondering, the reason that dependencies can change after install is that the live ebuild dependencies are used as a workaround for problematic dependencies such as those generated qt3.eclass and it's QT3VERSIONS variable (see bug #239006, comment #4 for more details). Anyway, I intend to solve poor depclean behavior that you've reported by using ebuilds to complete the dependency graph when possible, which should make it safer for --depclean to tolerate missing dependencies. OK, thanks a lot for the explanation :-) *** Bug 266647 has been marked as a duplicate of this bug. *** *** Bug 266861 has been marked as a duplicate of this bug. *** Is this still a problem? Depclean now suggests an emerge command with --with-bdeps=y in it What we really need as an emerge command that will attempt to perform the minimal changes necessary to correct the identified problems. In its simplest form, it would essentially take the unresolved dependencies and essentially feed those as arguments to emerge --oneshot (and as usual the user can add --usepkg if they'd like to use binary packages for this). (In reply to Zac Medico from comment #6) > What we really need as an emerge command that will attempt to perform the > minimal changes necessary to correct the identified problems. In its > simplest form, it would essentially take the unresolved dependencies and > essentially feed those as arguments to emerge --oneshot (and as usual the > user can add --usepkg if they'd like to use binary packages for this). For broken built slot operator deps, we'd want it to omit the built slot/subslot component in the emerge argument, so that it can rebuild against a new slot/subslot if needed. Planning an @unsatisfied-deps package set for this. Patch posted for review: https://archives.gentoo.org/gentoo-portage-dev/message/69effbf850df926383164b0403840748 https://github.com/gentoo/portage/pull/731 (In reply to Zac Medico from comment #8) > Planning an @unsatisfied-deps package set for this. It turns out that @unsatisfied-deps is not really the solution to this bug, because it is often unsuitable in the sense that it pulls in a bunch of @installed packages (@preserved-rebuild has a similar caveat), when you really want to use @world as the source of truth. (In reply to Zac Medico from comment #10) > (In reply to Zac Medico from comment #8) > > Planning an @unsatisfied-deps package set for this. > > It turns out that @unsatisfied-deps is not really the solution to this bug, > because it is often unsuitable in the sense that it pulls in a bunch of > @installed packages (@preserved-rebuild has a similar caveat), when you > really want to use @world as the source of truth. My plan is it introduce an @unsatisfied-world set which is equivalent to @unsatisfied-deps but filters out any non @world packages. |