On Fri, 2013-07-05 at 22:18 -0400, Rick "Zero_Chaos" Farina wrote: > On 07/05/2013 09:41 PM, Ryan Hill wrote: > > On Fri, 05 Jul 2013 15:47:08 -0400 > > "Rick \"Zero_Chaos\" Farina" <zeroch...@gentoo.org> wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >>> Paweł was nice enough to write a patch for us to get toolchain.eclass up > >>> to > >>> EAPI 5. I believe it still needs some pieces like prefix support and I > >>> haven't reviewed it in depth but it looks good so far (and much simpler > >>> than I thought (oops)). I'm planning on moving up an EAPI at a time, > >>> bumping it whenever we could use new features or people start hucking > >>> fruit. > >>> > >>> > >> I would be forever in your debt if toolchain were on eapi 5 and had > >> proper subslot deps. > > > > What use case are you encountering? I hadn't planned on using subslots, but > > I'm open to good reasons/bribery. > > > > > > Livecd builds work like this: > > stage3 tarball is unpacked, then toolchain (minimum package set) is > built with ROOT=/tmp/stage1root and is linked to the original (seed > stage) while being built. > > When we then move onto stage 2, it uses just the packages built during > stage1 (/tmp/stage1root becomes /). This means, if seed stage has > mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in > stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. > > To combat this kind of failure we are currently running "emerge --update > --deep --newuse --complete-graph --rebuild-if-new-ver gcc" which could > just be "emerge --update gcc" if eapi 5 subslots were used properly. > > Please forgive me if any of these details aren't perfect, I'm using my > best recollection of the most recent issue which happened when mpc was > bumped a few months ago. > > I am available on irc quite a bit if you would like to discuss, however, > if you want to keep it on the ML we really need to move this to -dev. > > Thanks, > Zero
Continuing this on -dev mail list. The other thing we needed to do was completely remove the use of or building of binpkgs during the update_seed stage. Portage has no capability to check binpkg linking to ensure the binpkg was properly usable. EAPI 5 subslots also put that info into the DEPENDS so portage then considers that information. It would then reject a binpkg properly and build from source due to the abi mismatch. I might also add that using broken binpkgs in catalyst (like the mpc update) cause delayed breakage, making trouble shooting the problem more difficult. With proper use of subslots for base system pkgs, binpkgs can be re-used safely, saving both build and turn around time to get fully working stages and livecd's etc. in catalyst released. The same holds true for user systems that build and try to reuse binkgs.
