There are two types of blocked packages. The first type is shown as [b] by the emerge tool, and it means that the block can be handled by emerge automatically. The second type is displayed as [B] and it means that there's some serious problem with the portage, manual steps are required to proceed. The 'A Portage Introduction' guide in its 'Blocked Packages' leaves readers under impression that there is just one type of blocked packages, and each type portage complains about a blocked package manual resolution is required. Maybe it's just me, but until recently I was doing emerges with --pretend flag, then emerge was 'Complaining' about blocked packages, and I referred to the 'Blocked Packages' section of the Guide to search the solution. Thanks to the IRC guys who taught me about the two types of blocks in Portage. Reproducible: Always Steps to Reproduce: 1. See portage complaining about blocked packages 2. Go to http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap4 and open Blocked Packages section 3. The section misleads you to manually process the blocks Expected Results: The Guide should mention the two types of blocks, preferably with [b] and [B] samples.
Ok, you guys are liars. I've just had [B] blocks reported by emerge --pretend, but they were handled by emerge You really must to figure out the difference between [B] and [b] blocks and document it in a GOOD MANNER
Abusing developers who haven't previously been made aware of the new changes in emerge output won't get things fixed. Also, not all B blocks are automatically resolved. Try installing xf86-video-ati, mesa-9999, and a 2.6.32 kernel, and then try merging ati-drivers. Blam, hard [B] block that's not resolved automatically. Portage's block resolving feature varies from package to package. Marking as WONTFIX for now -- until the docs-team can decide how to come up with a generic approach, and until the reporter is less abusive.
Abusing developers appeared to be the only practical way to attract attention to the issue. This is very sad indeed. Could you please specify which issue in the bugzilla is assigned for them to 'decide how to come up with a generic approach'? So that we could close this one. Thanks
Newer portage is versions include enhanced blocker resolution. So it will depend on which version of portage you have installed. This makes it hard for the documentation to be kept current. Please include emerge --info sys-apps/portage
Created attachment 211461 [details] $ emerge --info sys-apps/portage > /tmp/emergeinfo.txt emerge --info sys-apps/portage is attached. It was my understanding that documentation is done for a concrete release of Gentoo (profile), and each release (profile) defaults to a concrete portage version. Is this not true?
I think that I'm using the latest profile: $ ls -l /etc/make.profile lrwxrwxrwx 1 root root 55 2009-10-26 21:58 /etc/make.profile -> ..//usr/portage/profiles/default/linux/x86/10.0/desktop
It is my understanding that the goal of the documentation is to be based on current stable. If I install today using the latest autobuild, my install next week with the current stable autobuild may install an updated portage version. So the documentation for portage that is ok today may not be correct next week. This is the type of documentation that may be better to remove and refer users to use the installed documentation as reference. e.g man portage Just my 2c.
(In reply to comment #7) > It is my understanding that the goal of the documentation is to be based on > current stable. I'm always using current stable, that's why I was surprised with current stable portage behavior being not documented well. If your understanding matched the real state of things this issue would never get raised. 10.0 desktop is stable isn't it? I tried to stay on 2008 as long as possible and switched to 10.0 only when 2008 became unsupported and emerge instructed me to upgrade.
@Oleg Mikheev: Please reconsider your attitude when opening a bug as getting developers to work with you will be much easier if you don't start "attacking" people and labeling Gentoo developers as "liars". Please read the Gentoo "Code of Conduct" and follow it as it applies to all communication mediums. [1] - http://www.gentoo.org/proj/en/council/coc.xml About the blocks, the new block resolution behaviour was introduced with EAPI-2[2] and thus has long been in the stable tree. You may want to read more details in the Portage Documentation[3], specifically in the "Blocker Conflicts"[4] section. [2] - http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-2-draft-metadata-dependencies-blocker-atoms [3] - http://dev.gentoo.org/~zmedico/portage/doc/portage.html [4] - http://dev.gentoo.org/~zmedico/portage/doc/portage.html#dependency-resolution-package-modeling-blocker-conflicts
(In reply to comment #9) > Please reconsider your attitude when opening a bug as getting developers to > work with you will be much easier if you don't start "attacking" people and > labeling Gentoo developers as "liars". Please read the Gentoo "Code of Conduct" > and follow it as it applies to all communication mediums. I will reconsider my personal attitude and it will follow the Gentoo "Code of Conduct". My reaction was most probably a response to developers who told me on the IRC communication medium that [B] conflicts differed from [b] conflicts in the way that [B]s should me fixed manually, unlike [b], which will be handled by emerge automatically. That was a false statement (after some time spent on manual fixing I ran emerge without --pretend and it resolved [B]s automatically) and it received an adequate response from a person who hadn't read the Gentoo "Code of Conduct". Reading the documents from the referenced documents didn't give me a clue about B and b differences. The emerge man page provides some info, but it copies what the ICR communication medium said. There's a good chance of false output from the emerge (B instead of b) in my case. Nevertheless [B] and [b] differences could and probably should be documented/
