| Summary: | portage and bash blocking each other | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | myrddyn |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | major | CC: | arjenpool, bensberg, brainless, esigra, jordi.sola, oracleguy01, rajiv |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
myrddyn
2008-04-13 02:14:39 UTC
You'll have to mask the bash update until portage has been updated. Something like this should work: echo ">=app-shells/bash-3.2_p33" >> /etc/portage/package.mask emerge portage After you've done that, you should be able to remove the bash atom from /etc/portage/package.mask and update bash: emerge bash *** Bug 222001 has been marked as a duplicate of this bug. *** *** Bug 221987 has been marked as a duplicate of this bug. *** *** Bug 223191 has been marked as a duplicate of this bug. *** Masking bash does not solve the problem because portage pulls it as a dependency and the blockage persists. The solution is to emerge portage without dependencies: emerge -avO portage emerge -av0 emerge can also be replaced by emerge '<app-shells/bash-3.2_p33' that one did the work in my gentoo. (sorry for previous typos) emerge -avO portage ; emerge bash can also be replaced by emerge '<app-shells/bash-3.2_p33' ; emerge portage It did the trick in my gentoo. (In reply to comment #7) > emerge '<app-shells/bash-3.2_p33' ; emerge portage So how can we get this fixed so that it does the update automatically, without users having to type in this command or use one of the other hacks above? (In reply to comment #8) > So how can we get this fixed so that it does the update automatically, without > users having to type in this command or use one of the other hacks above? That type of blocker is already solved automatically by newer versions of portage. The problem is that people are upgrading from old versions of portage, so they don't have the benefit of the new automatic blocker resolution. (In reply to comment #9) > (In reply to comment #8) > > So how can we get this fixed so that it does the update automatically, without > > users having to type in this command or use one of the other hacks above? > > That type of blocker is already solved automatically by newer versions of > portage. The problem is that people are upgrading from old versions of portage, > so they don't have the benefit of the new automatic blocker resolution. I'd like to point out the fact that Gentoo won't acquire many new users as long as this problem persists. If I was a Gentoo newbie and followed the instructions character by character, I'd be mildly upset. I took stage3-i686-2007.0.tar.bz2 and portage-20080616.tar.bz2 this week to setup a new machine, and ran into this bug. The only solution is to provide a stage3 update that contains newer bash and portage versions, right? The 2007.0 stages are a bit old now. It's better to use the 2008.0 beta stages. Hopefully the final 2008.0 stages will be out soon. (In reply to comment #11) > The 2007.0 stages are a bit old now. It's better to use the 2008.0 beta stages. > Hopefully the final 2008.0 stages will be out soon. > I was using 2008.0 beta when I encountered this problem. If you're getting a blocker between portage and bash when installing from the 2008.0 stages then it's probably because you've managed to trigger the new blocker from bug #222721. You should only hit that one if you've unmasked unstable bash without unmasking unstable portage. Once you've unmasked the correct versions of both portage and bash then the blocker should resolve automatically. (In reply to comment #13) > If you're getting a blocker between portage and bash when installing from the > 2008.0 stages then it's probably because you've managed to trigger the new > blocker from bug #222721. You should only hit that one if you've unmasked > unstable bash without unmasking unstable portage. Once you've unmasked the > correct versions of both portage and bash then the blocker should resolve > automatically. > I never unmasked unstable bash (in fact, at the time this happened I had not unmasked any unstable packages on my system), and I still encountered this blocker. (In reply to comment #14) > I never unmasked unstable bash (in fact, at the time this happened I had not > unmasked any unstable packages on my system), and I still encountered this > blocker. That doesn't seem possible. The 2008.0 beta stages contain portage-2.1.4.4 which is only blocked by bash-3.2_p39, and bash-3.2_p39 still has unstable keywords, as shown here: http://packages.gentoo.org/package/app-shells/bash I suppose if you post the emerge output showing the blockers, then we might gain a better understanding of the problem. I see the same bug. This is how I produced it:
I ran "emerge --sync" for the first time since July 2006. After the sync, emerge told me to run "emerge portage" because there was an update to portage.
So I run "emerge -a portage" and this is the output:
kip etc # emerge -a portage
These are the packages that would be merged, in order:
Calculating dependencies
Parse Error reading PROVIDE and USE in '/var/db/pkg/x11-base/xorg-x11-6.8.2-r6'
Possibly Invalid: 'virtual/x11 opengl? virtual/opengl opengl? virtual/glu virtual/xft'
Exception: Conditional without parenthesis: 'opengl?'
... done!
[blocks B ] <sys-apps/portage-2.1.4_rc1 (is blocking app-shells/bash-3.2_p33)
[ebuild U ] sys-apps/sandbox-1.2.18.1-r2 [1.2.17]
[ebuild U ] net-misc/rsync-3.0.3 [2.6.0-r6] USE="acl* iconv%* ipv6%* -xattr% -xinetd%"
[ebuild U ] dev-python/pycrypto-2.0.1-r6 [2.0.1-r5]
[ebuild U ] sys-apps/portage-2.1.4.4 [2.1.2-r9]
*** Portage will stop merging at this point and reload itself,
then resume the merge.
[ebuild U ] app-shells/bash-3.2_p33 [3.0-r12] USE="-afs% -plugins% -vanilla%"
!!! Error: The above package list contains packages which cannot be installed
!!! at the same time on the same system.
For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
I then followed the instructions found at http://www.gentoo.org/doc/en/gentoo-upgrading.xml to upgrade to the 2008.0 profile. But "emerge -a portage" produces the same bug.
(In reply to comment #16) > [blocks B ] <sys-apps/portage-2.1.4_rc1 (is blocking > app-shells/bash-3.2_p33) > [ebuild U ] sys-apps/portage-2.1.4.4 [2.1.2-r9] > [ebuild U ] app-shells/bash-3.2_p33 [3.0-r12] USE="-afs% -plugins% > -vanilla%" The recommended solution for this type of situation is to temporarily mask the higher versions of bash which are incompatible with versions of portage less than 2.1.4_rc1. For example: echo ">=app-shells/bash-3.2_p33" >> /etc/portage/package.mask emerge portage After you've upgraded to portage-2.1.4.4, removed the above mask from /etc/portage/package.mask and then upgrade bash: emerge -1 bash (In reply to comment #1) > You'll have to mask the bash update until portage has been updated. Something > like this should work: > > echo ">=app-shells/bash-3.2_p33" >> /etc/portage/package.mask > emerge portage > > After you've done that, you should be able to remove the bash atom from > /etc/portage/package.mask and update bash: > > emerge bash > I was updating a server which hadn't been synced since May 2007 and had this bug. This solution worked for me, once I temporarily masked the new bash version, portage was able to update. If this issue doesn't happen in the future with the new portage version, then I don't see it as a big deal. However if this is happening with the 2008.0 stage3, then there is a big problem and the stage needs to updated. This isn't only going to be a pain for new users but an annoyance for seasoned users as well. Given the current state of the portage tree, if you have any problems with portage and bash blocking each other when installing the 2008.0 stages then it's because you've triggered the blocker from bug #222721 by mixing stable and unstable versions of portage and bash (as explained in comment #13). Once you've unmasked the correct versions of both portage and bash then the blocker should resolve automatically (without any user intervention). When I had the following set of packages installed, there was no way to get an upgrade by adding things to /etc/portage/package.keywords, like some had suggested: sys-apps/portage-2.2_rc12 app-shells/bash-3.2_p39 app-admin/eselect-1.0.10 (I had "=app-shells/bash-3.2_p39 ~x86" in /etc/portage/package.keywords because older versions did not work with UTF-8.) What I had to do was to add this to /etc/portage/package.keywords: =sys-apps/portage-2.1.5* ~x86 Then I executed this: emerge --oneshot --nodeps portage bash (In reply to comment #20) > emerge --oneshot --nodeps portage bash It might work to use --nodeps in some cases but it's not recommended. The blockers exist for a reason and --nodeps causes them to be ignored. If you have both unstable bash and unstable portage unmasked, and the blockers don't solve automatically, generally it means that you haven't installed from 2008.0 stages and you haven't been updating regularly. In this case, the recommended approach is to first upgrade to bash-3.2_p17-r1, since this version is compatible with both older and newer versions of portage. Once you've got bash-3.2_p17-r1 installed, upgrade to the latest portage. Once you've got the latest portage, you can upgrade to the latest bash. |
