| Summary: | portage fails to resolve trivial blocker | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Victor Mataré <vmatare+gbug> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2.2 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
sorry, I meant to say "portage should UNinstall and then reinstall" vlc has a hard blocker !! to itself on purpose, to avoid old vlc being installed when new one is compiling (so it won't use the installed parts for the new compilation from system) *** This bug has been marked as a duplicate of bug 277430 *** Thanks for that info. However the reason for the blocker was only a side question. This bug is actually about portage's depency conflict resolver, which I think should automatically decide to uninstall and then reinstall vlc. So I'll reopen it if you don't mind. *** This bug has been marked as a duplicate of bug 250286 *** |
When updating, I get this: [ebuild U ] media-video/vlc-1.1.4 [1.0.6] USE="kde%* -libv4l% -projectm% -sqlite% -vaapi%" [blocks B ] <=media-video/vlc-1.0.99999 ("<=media-video/vlc-1.0.99999" is blocking media-video/vlc-1.1.4) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (media-video/vlc-1.1.4, ebuild scheduled for merge) pulled in by media-video/vlc required by (virtual/matare-desktop-0.5.3, installed) Now the virtual doesn't care if vlc is 1.1.4 or 0.9 or whatever. So portage should just install and then reinstall vlc like it does in many other scenarios. Actually I don't see why it shouldn't work in this situation. BTW, what's the matter with these vlc blockers, anyway? They're not slotted, thus can't be installed simulateously, so why block at all?