| Summary: | sys-devel/binutils: USE=multislot conflicts with new portage-2.1.2_pre2-r4 slotted behavior | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
| Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jakub |
| Priority: | High | Keywords: | InVCS, REGRESSION |
| Version: | 2006.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=150361 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 147007 | ||
| Attachments: |
emerge --info
don't pull unavailable slots in with system and world |
||
|
Description
Duncan
2006-10-06 04:43:07 UTC
Pls give emerge --info Created attachment 98929 [details]
emerge --info
emerge --info (minus certain local fs paths info, this /is/ a public site, after all, and that's on a need-to-know basis)
Nice junk in C[XX]FLAGS... Kindly don't report any compile bugs with this. See this patch: http://dev.gentoo.org/~zmedico/portage/branches/2.1/patches/installed_deps/installed_deps-2.1.2_pre2-r4.patch > Nice junk in C[XX]FLAGS... Kindly don't report any compile bugs with this.
off topic and has nothing to do with the issue at hand
This is fixed in 2.1.2_pre2-r5. *** This bug has been marked as a duplicate of 48195 *** Thanks, and on the CFLAGS, don't worry, if I can add to CFLAGS, I can just as easily remove from CFLAGS, as routinely do before bug reports or as necessary. =8^) That said, -combine and FEATURES=confcache are the only ones that seem to cause problems, and that's seldom enough I can deal with it when it occurs. A couple of the others are known to have issues on x86, but I'm not on x86, or I'd likely not be using them. Note that the fix for bug 48195 doesn't solve all issues with multislot packages. For example, some of the slots may not update automatically with world like one would hope and will not be remerged via --emptytree. What's really needed is some new type of ebuild metadata indicating dynamic slots that may be available. I meant to leave this as a duplicate. Proper dynamic slots support should be proposed via a GLEP. *** This bug has been marked as a duplicate of 48195 *** (In reply to comment #6) > Thanks, and on the CFLAGS, don't worry, if I can add to CFLAGS, I can just as > easily remove from CFLAGS, as routinely do before bug reports Not even much funny... You are asking for your compile bugs to be marked INVALID on the fly, probably. (In reply to comment #7) > Note that the fix for bug 48195 doesn't solve all issues with multislot > packages. For example, some of the slots may not update automatically with > world like one would hope and will not be remerged via --emptytree. What's > really needed is some new type of ebuild metadata indicating dynamic slots Seems to work nicely, actually: # emerge -uDpv world These are the packages that would be merged, in order: Calculating world dependencies... done! [ebuild U ] sys-devel/binutils-2.17.50.0.3-r1 [2.17.50.0.3] USE="multislot -multitarget nls -test -vanilla" 0 kB # qlist -CIev binutils sys-devel/binutils-2.17.50.0.3 sys-devel/binutils-2.17.50.0.5 # emerge -epv system | grep binutils [ebuild N ] sys-devel/binutils-config-1.9-r2 0 kB [ebuild N ] sys-devel/binutils-2.17.50.0.5 USE="multislot -multitarget nls -test -vanilla" 0 kB [ebuild N ] sys-devel/binutils-2.17.50.0.3-r1 USE="multislot -multitarget nls -test -vanilla" 0 kB We've got the same problem again in 2.1.2_pre2-r6 due to out masking check not being sort of a hack (bug 149816). Created attachment 99162 [details, diff] don't pull unavailable slots in with system and world This fix, in svn r4619, prevents the greedy system and world behavior (bug 4698) from pulling in unavailable slots. This has been released in 2.1.2_pre2-r7. (In reply to comment #9) > (In reply to comment #6) > > Thanks, and on the CFLAGS, don't worry, if I can add to CFLAGS, I can just as > > easily remove from CFLAGS, as routinely do before bug reports > > Not even much funny... You are asking for your compile bugs to be marked > INVALID on the fly, probably. I think you misunderstood, perhaps as I missed the crucial bit. If I can add to CFLAGS, I can just as easily remove from CFLAGS and try again before bugfiling. That's what I meant, not that I remove CFLAGS as actually used from the reports filed, which is I think how you took it. I'm not /that/ devious =8^), and yes, I agree, that wouldn't be funny at all! =8^( |
