| Summary: | Old style virtuals are higher priority than new style | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Radoslaw Szkodzinski <astralstorm> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2.2 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Forgot this: Portage 2.2_rc88 (hardened/linux/amd64/10.0, gcc-4.4.4, glibc-2.12.1-r0, 2.6.35-ck1+ x86_64) It's not a matter of "priority". What you're trying to do would work perfectly fine if you removed the blocker from the mit-krb5-1.8.3 ebuild. If you're transitioning to new-style virtuals then that blocker doesn't make sense anyway. Given the blocker, portage is behaving correctly. It wouldn't be right for portage to ignore the blocker. |
I've found this issue while trying to merge a new style virtual. Suppose we have an old virtual package app-crypt/mit-krb5, which has PROVIDES="virtual/krb5" Now I created a new /usr/local/portage/virtual/krb5/krb5-0.ebuild, which contains RDEPEND="|| ( app-crypt/heimdal app-crypt/mit-krb5 )" Unfortunately, this is the result of trying to merge it: [ebuild N ] virtual/krb5-0 0 kB [0=>1] [blocks B ] app-crypt/mit-krb5 ("virtual/krb5" is blocking app-crypt/mit-krb5-1.8.3)