Summary: | emerge @preserved-rebuild attempts to emerge gcc from non-existent slot (system type in slot identifier) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nico R. <n-roeser> |
Component: | [OLD] Unspecified | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | daniel.santos, esigra, pacho |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 287900 | ||
Bug Blocks: | 240323 |
Description
Nico R.
2008-09-20 22:53:13 UTC
It's triggered by the "multislot" USE flag, which modifies SLOT in a way that it was never designed to be modified. Ah, I see, thanks. But I’ve been using ‘multislot’ for quite a while, and it /used to/ work (until a few weeks ago, IIRC). Well, things change. Portage uses the SLOT value in more places than it did in the past. so what is the work-around? I'm enjoying this bug as well. I haven't kept up with portage changes so this preserved-libs feature came as a surprise to me (one day I'll switch from ~amd64 to amd64). The contents of /var/lib/portage/preserved_libs_registry don't look very hacker-friendly either. For example, if you have this problem with sys-devel/gcc-4.1.2 then you can fix it like this: echo 4.1.2 > /var/db/pkg/sys-devel/gcc-4.1.2/SLOT touch /var/db/pkg/sys-devel/gcc-4.1.2 (In reply to comment #5) > For example, if you have this problem with sys-devel/gcc-4.1.2 then you can fix > it like this: > > echo 4.1.2 > /var/db/pkg/sys-devel/gcc-4.1.2/SLOT > touch /var/db/pkg/sys-devel/gcc-4.1.2 > Actually, the correct SLOT in that case is 4.1 so you'd really do this: echo 4.1 > /var/db/pkg/sys-devel/gcc-4.1.2/SLOT touch /var/db/pkg/sys-devel/gcc-4.1.2 |