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