Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 215096 - trying to emerge multiple masked packeges only reports first one
Summary: trying to emerge multiple masked packeges only reports first one
Status: RESOLVED DUPLICATE of bug 280097
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 236225 253845 281185 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-03-27 19:56 UTC by Christopher Smith
Modified: 2010-12-02 01:37 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Smith 2008-03-27 19:56:26 UTC 
When running emerge on a list of several packages, more than one of which is masked (say by the ~x86 keyword on a x86-only system), portage exits after listing just the first masked package.  When performing a revdep-rebuild, for instance, this can require dozens of false starts before getting the system updated, since the user can't issue a single "ACCEPT_KEYWORDS=~arch emerge <packages>" command.

portage should list all masked packages, as it does with blocked packages.

Reproducible: Always

Steps to Reproduce:
Try to emerge more than one masked package.
Actual Results:  
portage reports the first masked package but not the other(s)

Expected Results:  
portage should report all problems with masked packages
Comment 1 Zac Medico gentoo-dev 2008-03-28 22:49:26 UTC 
I think you have a valid request, but generally, it's better practice to use the autounmask program (from the app-portage/autounmask package) to unmask packages instead of overriding ACCEPT_KEYWORDS via the environment.
Comment 2 Christopher Smith 2008-03-29 02:37:31 UTC 
In this case, the actual underlying issue was not a masking problem, but rather treated as a masking problem by portage and resolved in the same way.  Specifically, revdep-rebuild can try to emerge specific atoms that no longer exist in the portage tree, and instead of reporting all of the missing ebuilds (which portage treats as having a null keyword), it only reports the first.  However, reporting all the masking problems at once will both fix the ~arch issue and the no-ebuild issue.
Comment 3 Wormo (RETIRED) gentoo-dev 2008-08-30 20:37:54 UTC 
*** Bug 236225 has been marked as a duplicate of this bug. ***
Comment 4 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2009-01-05 13:49:33 UTC 
*** Bug 253845 has been marked as a duplicate of this bug. ***
Comment 5 Mounir Lamouri (volkmar) (RETIRED) gentoo-dev 2009-08-12 12:16:04 UTC 
*** Bug 281185 has been marked as a duplicate of this bug. ***
Comment 6 Mounir Lamouri (volkmar) (RETIRED) gentoo-dev 2009-08-12 12:17:05 UTC 
Add depends on 280097 because Zac add it in duplicate bug 281185
Comment 7 Wyatt Epp 2010-12-01 20:36:57 UTC 
Is this bug not resolved by the addition of --autounmask (portage-2.1.9)?  Seems to work pretty well for me.
Comment 8 Zac Medico gentoo-dev 2010-12-02 01:36:02 UTC 

*** This bug has been marked as a duplicate of bug 280097 ***