| Summary: | Portage leaves no indication as to why some packages are being blocked | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Maurice Volaski <mvolaski> |
| Component: | New packages | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | esigra |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 155723 | ||
|
Description
Maurice Volaski
2008-01-16 21:18:25 UTC
*** This bug has been marked as a duplicate of bug 205890 *** No, it's not a duplicate or please reopen the other bug as an enhancement request. Please do not close this. It's an enhancement request. Please pass it onto the portage team and let them decide what to do with it. Once again - there's changelog for this, and --changelog emerge option to show the changelog entry related to this. Portage has no magic knowledge why someone did stick a blocker into an ebuild. If there's a missing changelog entry for something, then file a bug about that, not about blockers which are totally not a bug. What's is the changelog going to tell me? That the new version of portage is masked? Portage is being told update bash and it looks in the ebuild and sees it needs a new version of portage. But when it gets to emerge that, it sees that it is masked, so it can't let the emerge continue but it just reports that portage is blocking bash. There is no indication anywhere that it's because this new version of portage is masked. If it just had output to that effect, it could save a LOT of troubleshooting. Look at the two forum posts you referred to in the related bug report. Would they be there had portage made this announcement? To tell the truth, I seem to recall that in the past, sometimes portage does tell me this, so why is it not now? Perhaps this is a real bug, after all? (In reply to comment #5) > What's is the changelog going to tell me? That the new version of portage is > masked? No, it's not masked, you apparently don't get the point of blockers in ebuilds. Please move this out of bugzilla. http://www.gentoo.org/main/en/support.xml http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3 Of course, it's masked. Masked by keyword.. What else do you think is caused it be blocked? # $Header: /var/cvsroot/gentoo-x86/sys-apps/portage/portage-2.1.4.ebuild,v 1.1 2008/01/12 03:30:15 zmedico Exp $ inherit toolchain-funcs eutils flag-o-matic multilib DESCRIPTION="Portage is the package management and distribution system for Gentoo" HOMEPAGE="http://www.gentoo.org/proj/en/portage/index.xml" LICENSE="GPL-2" KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~sparc-fbsd ~x86 ~x86-fbsd" Kindly read http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3 *before* posting any further comments here. I don't know what you are trying to get at. Blocking is not even mentioned anywhere in this section you are referring to. So perhaps I should file a bug about these incomplete instructions! Blocking is described here: http://gentoo-wiki.com/FAQ_Blocked_Package And as you will see, it clearly indicates masking a package can cause it to block another, required package. That is what happened here, but in the past I do recall seeing portage appropriately tell me this, but perhaps that was only when it was hard masked. So this is looking more and more like a real bug. It doesn't report a package being masked when it is blocked and masked only by keyword. Portage has NO knowledge about blockers' *reason* unless someone stick an entry wrt that to the *ChangeLog*, once that's done, you can get the reason from changelog. File bugs about missing changelog entried, don't file bugs about missing paranormal skills in portage. And this blockers stuff has *zero* to do with masking Enough noise here, move to appropriate channels with this. Your explanation makes no sense to me at all. I will people on the forum to check it what you say... (In reply to comment #11) > I will people on the forum to check it what you say... Great, finally a proper place to chat. CLOSED, no need for more comments. Thanks. This seems to me like a valid enhancement request to me, similar to bug 88613. The resolver should be searching for more solutions and telling the user what needs to be unmasked. (In reply to comment #13) > The resolver should be searching for more solutions and telling the user what > needs to be unmasked. I guess I misunderstood the point of this bug and supposed user is requesting a package.mask equivalent for blockers stating the reason - which sounds rather troublesome at least. :) Sorry for mishandling this, accept my apology please. |
