From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B50DB1381F3 for ; Tue, 28 May 2013 17:59:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B231E07F4; Tue, 28 May 2013 17:59:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D8394E07F4 for ; Tue, 28 May 2013 17:59:43 +0000 (UTC) Received: from [192.168.1.210] (S010600222de111ff.vc.shawcable.net [96.49.5.156]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id CC77833DBAB for ; Tue, 28 May 2013 17:59:42 +0000 (UTC) Message-ID: <1369763980.3446.71.camel@big_daddy.dol-sen.ca> Subject: Re: [gentoo-catalyst] [PATCH 1/2] Fix update_seed use by not using nor building binary packages during the seed update. From: Brian Dolbec To: gentoo-catalyst@lists.gentoo.org Date: Tue, 28 May 2013 10:59:40 -0700 In-Reply-To: <51A4E0C3.3040104@gentoo.org> References: <1364353797-7607-1-git-send-email-jmbsvicetto@gentoo.org> <51A433BE.5040802@gentoo.org> <1369759349.3446.44.camel@big_daddy.dol-sen.ca> <51A4E0C3.3040104@gentoo.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Archives-Salt: 351400b7-93fe-4c76-a50b-13b0d4f1c3ba X-Archives-Hash: 2ec6b465141a25c38e10859073f4e7ee 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