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 D8B181381F3 for ; Tue, 28 May 2013 18:50:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0D185E0957; Tue, 28 May 2013 18:50:29 +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 7CB9AE0957 for ; Tue, 28 May 2013 18:50:28 +0000 (UTC) Received: from [192.168.1.4] (pool-71-245-176-92.pitbpa.fios.verizon.net [71.245.176.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id E3A8733DEE1 for ; Tue, 28 May 2013 18:50:26 +0000 (UTC) Message-ID: <51A4FC90.8000005@gentoo.org> Date: Tue, 28 May 2013 14:50:56 -0400 From: "Rick \"Zero_Chaos\" Farina" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130524 Thunderbird/17.0.6 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 To: gentoo-catalyst@lists.gentoo.org Subject: Re: [gentoo-catalyst] [PATCH 1/2] Fix update_seed use by not using nor building binary packages during the seed update. 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> <1369763980.3446.71.camel@big_daddy.dol-sen.ca> In-Reply-To: <1369763980.3446.71.camel@big_daddy.dol-sen.ca> X-Enigmail-Version: 1.6a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 4cc476e0-236b-4261-a9a0-c8677032075a X-Archives-Hash: ec253337daa2607b7a7508c592c7fa3a -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/28/2013 01:59 PM, Brian Dolbec wrote: > 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. In fact, the command is "--rebuild-if-new-ver" not "--reinstall-if-new-ver". As such, the original reporter of this bug and I both seem to think that even with --usepkg, gcc should be rebuilt: https://bugs.gentoo.org/show_bug.cgi?id=461422 That's obviously not how it is, but I feel we should focus our attention on fixing this properly. > > 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. As a rule, we don't want to hack around limitations in portage to make catalyst work. The toolchain team seems to have made it very clear they aren't updating to eapi5 soon, but the portage team has been fixing things left and right based on little more than my whims, I'd give them a chance to fix this before throwing hacks into catalyst to work around limitations in the package manager. Thanks, Zero > > >>> 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. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpPyQAAoJEKXdFCfdEflKM1oQALB5UV+N2Qeou3MVRuW4vx4w 88yHebh8Vm2wihhIk8iJeoUw05uHTpu6DlTcO0f7cjpqRpTc61ULYss+/YWFVbGv PIB7uRquQv/aDFkfctSuUEYsVN94HmHB23T+tKHUPoGNWbmggvu4Y/z2nGAP6cNK WbXx+6qvpMLK5LqN9+y9QB5Ml3of02i4brs1r42wUFxp6u/A4usuMq7s4hIoHUAh RlxOIZPUCLxUV8BNNqsKsEOxFEZyawBnVAhUrp9C/GX4BvqsMeeT1R9KtgCjmcFI lBtmyu4PVOUe/uBvfJd6CS3zpyx8ZY3/+BJzSEX7kB9ael2Ejg1JtGJFxQIC1RbL /ctK2PBmiJ4BTGvzYN9HkgSqvsv6K+0IIsV2450oKd+CoyEeQ1M+Nj2NODVs+Io3 i3YyVDyZZzRqphdB8RBDLrrQ0ADuA9kRWNWTffaqla5l5pcdZs9EH87Kbvue2fZw ISe50Bc1RPKePrhRthcP3OgaelU3YALDwOD2Apt+VGFAEmlByqwU2biqSXs6L/5v zbPlvazqFjBPqDpJclIc8ETNUSqP5ODN2KesmZVd0pOSIsyDOjZoZL++HzRqtSrO +vtRDXAq1kpFS25Frbd5yDbNQm+Qm9dVOWm6WJuG6kPwOW2AuI1m0lABFobo0nSr NApls/UNICUhjIGZQsKZ =5YP8 -----END PGP SIGNATURE-----