| Summary: | || ( x y ) prefers y if any version of y and no version of x is installed | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Nicolas Litchinko <nicolas> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | aaron, betelgeuse, gengor, jakub, john_r_graham, lars.langhans, maxicombina, pacho, truedfx, xijiaosdq |
| Priority: | High | ||
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Nicolas Litchinko
2007-01-13 22:04:12 UTC
This is the intended behavior. Sorry, you'll just have to accept it. This is intended even when the installed version of y is in a different slot? If so, the libstdc++ example really should prefer libstdc++-v3 over gcc-3.3, so is there some alternative that can be used in the ebuild? (In reply to comment #2) > This is intended even when the installed version of y is in a different slot? Yes, the preference effect crosses slot boundaries since the presence of a given package (regardless of slot) is a general indication that the package is preferred over other possible choices. Of course there may be some cases where this preference algorithm chooses something different that what the user would truly prefer. In that case, the user can manually install the desired package or to mask the unwanted package. > If so, the libstdc++ example really should prefer libstdc++-v3 over gcc-3.3, so > is there some alternative that can be used in the ebuild? The only alternative at the ebuild level is to remove gcc as a choice. (In reply to comment #3) > (In reply to comment #2) > > If so, the libstdc++ example really should prefer libstdc++-v3 over gcc-3.3, so > > is there some alternative that can be used in the ebuild? > > The only alternative at the ebuild level is to remove gcc as a choice. > echo "virtual/libstdc++ minimal" >> ${PORTDIR}/profiles/base/package.use RDEPEND="|| ( =sys-libs/libstdc++-v3-3.3* !minimal? ( =sys-devel/gcc-3.3* ) )" (In reply to comment #4) > echo "virtual/libstdc++ minimal" >> ${PORTDIR}/profiles/base/package.use > RDEPEND="|| ( =sys-libs/libstdc++-v3-3.3* !minimal? ( =sys-devel/gcc-3.3* ) )" I think that's kind of an ugly way to do it. If it's really necessary to prevent gcc-3.3* from being pulled in, I think a better solution would be to mask gcc-3.3* in the relevant profiles (since most people won't be using gcc-3.3* anymore anyway). I've just noticed that GLEP 37 mentions a package.prefer that has never been implemented: http://www.gentoo.org/proj/en/glep/glep-0037.html#overrides Something like that should be helpful for situations like this bug. Hi!
I believe this strange thing happend to you (as well as with me), because you are using a profile not the one you are used to! (the x86/no-ntpl requires gcc-3.3.6-r3 with libstdc++ BUT the simple 2006 profile does not.)
Cheers!
Semir
Some more things: if ACCEPT_KEYWORDS=~x86 is set in /etc/make.conf, it will still emerge gcc-3.3.6.
Do: 1. remove ACCEPT_KEYWORDS=~x86 from make.conf
2. (correct symlinks of /etc/make.profile. Actually now I dont really know if it has anything to do with this bug :])
3. echo "sys-devel/gcc ~x86" >> /etc/portage/package.keywords
Before:
emerge -u --newuse --deep -p world | grep gcc
[ebuild U ] sys-devel/gcc-config-1.3.15 [1.3.13-r3]
[ebuild NS ] sys-devel/gcc-3.3.6-r1 USE="gtk nls test (-altivec) -bootstrap -boundschecking -build -doc -fortran -gcj (-hardened) -ip28 -ip32r10k (-multilib) -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -vanilla"
After:
emerge -u --newuse --deep -p world | grep gcc
[ebuild U ] sys-kernel/linux-headers-2.6.17-r2 [2.6.11-r2] USE="-gcc64%"
[ebuild U ] sys-devel/gcc-config-1.3.14 [1.3.13-r3]
[ebuild N ] x11-misc/gccmakedep-1.0.2 USE="-debug
Quite like some shampoo, isnt it? :D
Hope, now I really solved it!
> Some more things: if ACCEPT_KEYWORDS=~x86 is set in /etc/make.conf, it will
> still emerge gcc-3.3.6.
> Do: 1. remove ACCEPT_KEYWORDS=~x86 from make.conf
> 2. (correct symlinks of /etc/make.profile. Actually now I dont really
> know if it has anything to do with this bug :])
> 3. echo "sys-devel/gcc ~x86" >> /etc/portage/package.keywords
None of the above worked for me. I just put
<=sys-devel/gcc-3.3.4-r1
in /etc/portage/package.mask. Appears to be fine.
*** Bug 174201 has been marked as a duplicate of this bug. *** *** Bug 174201 has been marked as a duplicate of this bug. *** *** Bug 177099 has been marked as a duplicate of this bug. *** *** Bug 178752 has been marked as a duplicate of this bug. *** *** Bug 213936 has been marked as a duplicate of this bug. *** *** Bug 239390 has been marked as a duplicate of this bug. *** *** Bug 255790 has been marked as a duplicate of this bug. *** |
