[gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014

[Ryan Hill]

On Fri, 05 Jul 2013 21:27:46 -0700
Brian Dolbec <dolsen@g.o> 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" <zerochaos@g.o> 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