| Summary: | sys-apps/portage-2.2_rc44 fails to build @preserved-rebuild if one package doesn't exist | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Albert Zeyer <albzey> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | esigra |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=301640 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 238236, 240323 | ||
|
Description
Albert Zeyer
2009-10-06 13:48:53 UTC
I assume that you know about bug 238236. So, you want it to drop the unsatisfied atom and continue? That sort of behavior is useful for lots of cases. For example, anything operation involving the @installed set (@preserved-rebuild is a subset of @installed). What we need to do is mark these atoms as "optional", so that they don't cause the dependency resolver to bail out. No, sorry, didn't know about that bug report. Anyway, I never put that SLOT by hand. It must have been by some other Gentoo tool. (perhaps crossbuild packages?) So, the workaround is to just 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 (In reply to comment #2) > So, the workaround is to just 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 Yes, and disable USE=multislot if you'd like to avoid this problem in the future. (In reply to comment #3) > (In reply to comment #2) > > So, the workaround is to just 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 > > Yes, and disable USE=multislot if you'd like to avoid this problem in the > future. > What if I would like to install several GCC versions (same minor branch) at the same time? In this case, I had both 4.4.0 and 4.4.1 installed. As 4.4.0 had some bugs which made it anyway not really useable for me, this doesn't matter that much for now but it will perhaps matter later on. Perhaps let gcc-4.4.1 satisfy both the 4.4.1 slot and the 4.4 slot and for dependency/update calculation, use the one which was specified at installation, i.e. if I installed gcc-4.4.0:4.4 and I do an update, it will install gcc-4.4.1:4.4 but it wont if I had installed gcc-4.4.0:4.4.0? Well, just an idea... Have to think more about this how to solve this in a nice way... Well, the root problem is that USE=multislot causes the ebuild to break our rules which state that a given build must have a pre-defined SLOT that can be determined in advance. These ebuilds do have a pre-defined SLOT, but then the ebuild modifies it at build time, resulting in some other value that is not predictable by the package manager. What we need some way for the package manager to predict and control the SLOT. For example, bug 174407 suggests to do it with USE flags, but that approach has some inherent problems. Anyway, any approach that we do invent in the future will have to be part of a future EAPI specification. Such bugs are tracked by bug 174380. |
