On Tue, 2013-05-28 at 12:52 -0400, Rick "Zero_Chaos" Farina wrote: > On 05/28/2013 12:42 PM, Brian Dolbec wrote: > > On Tue, 2013-05-28 at 00:34 -0400, Rick "Zero_Chaos" Farina wrote:
> > I have 3 reasons for wanting this change done this way > > > > 1. If a spec or config enables the PKGCACHE option. It will add > > all the binpkg options to the emerge command. Due to the > > possible problem with using/creating binpkgs during the > > update_seed process. These options should not be set. Currently > Can you please describe how using binpkgs during update_seed is an > issue? I don't think all of us fully understand that, I know I don't. This was all discussed in irc and the catalyst list. But somehow you seemed to miss it all. Early this year, mpc had an updated version. The existing update_seed command: clst_root_path=/ run_merge "--buildpkg=n --update --deep --newuse --onlydeps gcc" updated mpc, consequently, libmps.so,2 was deleted. libmpc.so.3 was created. This broke the existing gcc pkg due to the missing lib. This means that gcc needs to be rebuilt in order to be linked to libmpc.so.3. The existing command excluded gcc from being built (the opposite to what is needed). This failure in gcc did not show up until stage2 I believe, and was a bit troublesome to pin down the cause. Which is why I changed that line to: clst_root_path=/ run_merge "--update --deep --newuse --complete-graph --rebuild-if-new-ver gcc" It may be slightly overkill with the --deep --complete-gragh but it removes potential problems in revdep-rebuild, so... NOW for how binpkgs play into this. Existing gcc binpkgs have been linked to libmpc.so.2 and portage does not check that all lib links exist before qualifying the binpkg to be installed. Therefore installing a gcc binpkg is a hit and miss proposition. Making it's use un-reliable. Therefore until the toolchain is migrated to eapi 5 with proper subslot use. Using binpkgs is unreliable for update_seed. While this may slow down the stage1 process some. It does make it more reliable, so that the releng team won't be wasting time tracking down errors that can be otherwise prevented. Binpkgs can be created and reused with some caution for the regular stage build. But some errors may similarly occur if the snapshot used is changed between runs without clearing or checking existing binpkgs. Again eapi 5 pkg migration will solve this. Hence the user beware warning. > > Also I have slightly different PKGCACHE options in my rewrite branch. I > > have added --binpkg-respect-use to them. It was brought to my attention > > early in testing to put them in a config to eliminate the problem of > > using binpkgs that were not compiled with them set correctly. > We should probably make this default, if everyone agrees I can drum up a > quick patch and add it. This is already default in my profile to > infinite success. > > thanks, > Zero > > It was you that told me about that option, which is why i added it as default when PKGCACHE is enabled. That is something that Jorge did not pick up in my proposed patch. I do not know why. Nothing was said as I recall. -- Brian Dolbec <[email protected]>
