Summary: | emerge -e @installed fails finding sys-devel/binutils:${CTARGET}-${BVER} with USE="multislot" | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Tharrrk <tharrrk> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | esigra, notordoktor |
Priority: | High | ||
Version: | 2.2 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 144480 |
Description
Tharrrk
2008-11-19 13:58:59 UTC
It looks like sooner setting SLOT to version nubmer was the default behavior, why did it change? It does the same with gcc. USE=multislot modifies SLOT in a way that it was never intended to be modified, and this makes it fundamentally incompatible with the way that @installed is currently implemented. If you must enable USE=multislot, an equivalent command that should work for you is `emerge -e @system @world`. (In reply to comment #2) > USE=multislot modifies SLOT in a way that it was never intended to be modified, > and this makes it fundamentally incompatible with the way that @installed is > currently implemented. If you must enable USE=multislot, an equivalent command > that should work for you is `emerge -e @system @world`. > I understand the need of having more complex SLOT definition when using crossdev for example. I think (not sure) that `emerge -s @system @world` won't rebuild kde-3* when kde-4* is installed, would it? The reason for rebuilding is very simple - using CFLAGS -mcpu=native -mtune=native with >=gcc-4.2 and then switching to less equipped CPU (Phenom->AthlonX2). The reason for using USE="multislot" is also very simple - some of the packages won't compile using gcc-4.3.2 Without multislot I would fall into very serious problems, I won't even be able to compile a new kernel. What would be your recomendation than? Fix eclasses or fix a way of using SLOTs? Thanks for your time. (In reply to comment #0) (In reply to comment #1) > It looks like sooner setting SLOT to version nubmer was the default behavior, > why did it change? > It does the same with gcc. It hasn't been changed. (In reply to comment #3) > The reason for using USE="multislot" is also very simple - some of the packages > won't compile using gcc-4.3.2 > Without multislot I would fall into very serious problems, I won't even be able > to compile a new kernel. That doesn't sound right. USE=multislot only allows certain toolchain packages to be installed for multiple architectures (and for gcc also allows installation of multiple micro releases). You can still install multiple gcc versions (like 4.1.x, 4.2.x and 4.3.x) without USE=multislot. I strongly recommend you remove USE=multislot, chances are that it will cause more problems in the future. (In reply to comment #3) > I understand the need of having more complex SLOT definition when using > crossdev for example. I think (not sure) that `emerge -s @system @world` won't > rebuild kde-3* when kde-4* is installed, would it? The world file supports SLOT atoms now, so for example, if you have both kde-base/kde-meta:3.5 and kde-base/kde-meta:4.1 listed in /var/var/lib/portage/world then both will be pulled in by `emerge -s @system @world`. You should have both SLOTs in your world file anyway in order to prevent `emerge --depclean` from removing them. the binutils eclass no longer sets $CTARGET in the SLOT and is thus static for cross-compilers, so portage no longer gets confused. with the other fixes, i don't think there's anything left to do here. |