Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 287900 - sys-apps/portage-2.2_rc44 fails to build @preserved-rebuild if one package doesn't exist
Summary: sys-apps/portage-2.2_rc44 fails to build @preserved-rebuild if one package do...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 238236 preserve-libs
  Show dependency tree
 
Reported: 2009-10-06 13:48 UTC by Albert Zeyer
Modified: 2022-07-20 23:44 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Albert Zeyer 2009-10-06 13:48:53 UTC
acompneu ~ # emerge @preserved-rebuild --keep-going
Calculating dependencies                ... done!

emerge: there are no ebuilds to satisfy "sys-devel/gcc:i686-pc-linux-gnu-4.1.2".
Comment 1 Zac Medico gentoo-dev 2009-10-06 15:34:33 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.
Comment 2 Albert Zeyer 2009-10-06 22:40:20 UTC
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

Comment 3 Zac Medico gentoo-dev 2009-10-06 23:51:09 UTC
(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.
Comment 4 Albert Zeyer 2009-10-07 00:21:33 UTC
(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...
Comment 5 Zac Medico gentoo-dev 2009-10-07 04:54:32 UTC
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.