Summary: | Describe both types of blocks (b and B) | ||
---|---|---|---|
Product: | [OLD] Docs on www.gentoo.org | Reporter: | Oleg Mikheev <mihel> |
Component: | Other documents | Assignee: | Docs Team <docs-team> |
Status: | RESOLVED NEEDINFO | ||
Severity: | minor | CC: | comrel |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap4 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | $ emerge --info sys-apps/portage > /tmp/emergeinfo.txt |
Description
Oleg Mikheev
2009-11-08 23:45:01 UTC
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/ |