| Summary: | [PATCH] portage could resolve blocker and slot conflicts better by upgrading also packages that are not in depgraph | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Vlastimil Babka (Caster) (RETIRED) <caster> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | IN_PROGRESS --- | ||
| Severity: | normal | CC: | bothie, doug, esigra, kingjon3377, nirbheek, non7top, notordoktor, pacho, poletti.marco, rhill, rusty.boat92, saint.snit, spatz, tb |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=543290 https://bugs.gentoo.org/show_bug.cgi?id=559354 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 155723, 300071 | ||
| Attachments: |
backtrack to force update of blocked packages
backtrack to force update of blocked packages |
||
|
Description
Vlastimil Babka (Caster) (RETIRED)
2009-10-27 22:56:46 UTC
Hm didn't check if --complete-graph=y makes any difference in the current portage. Assuming not. But maybe it would make sense to use this option in this case, if its slowing the resolution down? (In reply to comment #1) > Hm didn't check if --complete-graph=y makes any difference in the current > portage. Assuming not. Right, it makes no difference atm. Unsolved blockers simply cause it to bail out in any case. What we want to do is use the existing backtracking framework to create a logical package mask (masking the installed version of xorg-server, for example) and then restart the dependency calculation. We may also be able to use a lookahead mechanism in order to avoid the need for backtracking in some obvious cases. > But maybe it would make sense to use this option in this case, if its slowing > the resolution down? We might as well enable it in this case since it's safer and it probably won't add much time to the calculation, if any. *** Bug 299833 has been marked as a duplicate of this bug. *** Hmmm, I don't really get this behaviour...
$ emerge -pv =media-libs/gstreamer-0.10.28 =media-libs/gst-plugins-base-0.10.28
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] media-libs/gstreamer-0.10.28 [0.10.25] USE="nls -test" 3,092 kB
[ebuild U ] media-libs/gst-plugins-base-0.10.28 [0.10.25] USE="-debug nls" 2,289 kB
[blocks b ] <media-libs/gst-plugins-base-0.10.26 ("<media-libs/gst-plugins-base-0.10.26" is blocking media-libs/gstreamer-0.10.28)
Notably, I don't get any upgrade because of this "blocker" when running emerge -uD world so unless I resolve this manually I'll probably be stuck with outdated versions of the above forever.
--complete-graph makes no difference and that I don't get at all, there's tons of stuff installed here that depends on media-libs/gst-plugins-base and media-libs/gstreamer here. What's up here?
# emerge -u -D 3 -av world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] media-libs/gstreamer-0.10.28 [0.10.25] USE="nls -test" 3,092 kB [0]
[ebuild U ] media-libs/gst-plugins-base-0.10.28 [0.10.25] USE="-debug nls" 2,289 kB [0]
[ebuild U ] www-client/chromium-5.0.342.5 [5.0.307.11] USE="-bindist% ffmpeg plugins-symlink" 0 kB [0=>1]
[blocks B ] <media-libs/gst-plugins-base-0.10.26 ("<media-libs/gst-plugins-base-0.10.26" is blocking media-libs/gstreamer-0.10.28)
Total: 3 packages (3 upgrades), Size of downloads: 5,381 kB
Conflict: 1 block (1 unsatisfied)
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
('installed', '/', 'media-libs/gst-plugins-base-0.10.25', 'nomerge') pulled in by
=media-libs/gst-plugins-base-0.10* required by ('installed', '/', 'media-plugins/gst-plugins-taglib-0.10.17', 'nomerge')
>=media-libs/gst-plugins-base-0.10.20 required by ('installed', '/', 'app-cdr/xfburn-0.4.3', 'nomerge')
>=media-libs/gst-plugins-base-0.10 required by ('installed', '/', 'net-wireless/bluez-4.62', 'nomerge')
(and 42 more)
('ebuild', '/', 'media-libs/gstreamer-0.10.28', 'merge') pulled in by
>=media-libs/gstreamer-0.10.15 required by ('installed', '/', 'app-cdr/brasero-2.28.3', 'nomerge')
>=media-libs/gstreamer-0.10.25 required by ('installed', '/', 'media-plugins/gst-plugins-lame-0.10.13', 'nomerge')
=media-libs/gstreamer-0.10* required by ('installed', '/', 'media-plugins/gst-plugins-meta-0.10-r4', 'nomerge')
(and 23 more)
Eh... ???
(In reply to comment #5) That seems like a slightly different issue. Can you please file a new bug and post output for `emerge -puD --debug --backtrack=0 world` (and emerge --info as usual)? A patch can be found here: http://github.com/few/fews-portage-branch/tree/update_if_needed (In reply to comment #7) > A patch can be found here: > > http://github.com/few/fews-portage-branch/tree/update_if_needed Backtracking is one way to do it. I've also had a suggestion from davidjames@google to translate < blockers into pseudo-dependencies that pull in updates. Using this approach, we may be able to avoid triggering backtracking in the first place, so it would be more efficient. *** Bug 379509 has been marked as a duplicate of this bug. *** Created attachment 312147 [details, diff] backtrack to force update of blocked packages (In reply to comment #7) > A patch can be found here: > > http://github.com/few/fews-portage-branch/tree/update_if_needed Here's a rebase of that patch on current master. *** Bug 417165 has been marked as a duplicate of this bug. *** Created attachment 316015 [details, diff]
backtrack to force update of blocked packages
Here's a rebase of the patch, with a failing test case that seems like we should be able to handle if we tweak the logic a little.
*** Bug 424391 has been marked as a duplicate of this bug. *** *** Bug 493096 has been marked as a duplicate of this bug. *** *** Bug 540398 has been marked as a duplicate of this bug. *** *** Bug 543290 has been marked as a duplicate of this bug. *** *** Bug 558936 has been marked as a duplicate of this bug. *** *** Bug 556168 has been marked as a duplicate of this bug. *** |