Summary: | collision between x11-libs/qt-assistant-4.4.2-r1 and x11-libs/qt-4.3.3 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tomasz Radziszewski <alinoe> |
Component: | New packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | qt |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 261959 |
Description
Tomasz Radziszewski
2009-03-14 18:15:25 UTC
qt-4.3.3 should be unmerged by portage before installing any of the split qt 4.4 (or 4.5) packages, as they block each other. (In reply to comment #1) > qt-4.3.3 should be unmerged by portage before installing any of the split qt > 4.4 (or 4.5) packages, as they block each other. Actually, the way that it's designed to work is that it will merge the split ebuilds into place before uninstalling the older version. However, it will bail out due to a file collision if there is not an explicit blocker between the two packages which have colliding files. I see that the x11-libs/qt-assistant-4.4.2-r1 ebuild doesn't contain any blockers, so apparently it needs to block <qt-4.4. qt-assistant depends on qt-gui, which in turn depends on qt-core. And qt-core blocks <qt-4.4.0. So at the point qt-assistant fails, qt-core must be installed already, and this would have blocked qt-4.3 already. The key thing to note is that blockers are not considered to be transitive. If A depends on B and B blocks C, it does not necessarily imply that A blocks C. I understand. But because of the dependencies, you cannot install qt-assistant unless qt-core is already installed (as qt-core is the basis for all other split qt packages). And qt-core blocks <qt-4.4.0. So at the point qt-assistant is being merged, that blocker should already have been dealt with. I guess you're right. That particular issue is fixed in svn r12611 and released in portage-2.1.6.8. http://sources.gentoo.org/viewcvs.py/portage?view=rev&rev=12611 Anyway, it won't hurt anything to add a blocker to qt-assistant (and it will prevent older portage from bailing out in this case). (In reply to comment #5) > And qt-core blocks <qt-4.4.0. So at the point qt-assistant > is being merged, that blocker should already have been dealt with. Actually, given the behavior currently in portage-2.1.6.8, that will only work if there's no qt-4.4 upgrade in the merge list. If such an upgrade exists in there merge list then the uninstall of qt-4.3 is intentionally delayed until just after the qt-4.4 ebuild is installed. The reason for the delay is that upgrades normally occur in this fashion (old version is uninstalled just after the new version is merged into place). Doesn't this behavior seem logical? Since the qt-4.4 ebuild depends on qt-assistant, you get a file collision whenever the qt-4.4 upgrade happens to get pulled in. As per the intentional behavior described in comment #7, I've added blockers to the qt-assistant ebuilds. |