On Fri, 05 Jul 2013 21:27:46 -0700 Brian Dolbec <dol...@gentoo.org> wrote:
> 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. Thanks, these are good reasons. -- Ryan Hill psn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
