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 108B81381F3 for ; Tue, 28 May 2013 16:51:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9E30AE09E4; Tue, 28 May 2013 16:51:51 +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 0C952E09E4 for ; Tue, 28 May 2013 16:51:50 +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 052B133E140 for ; Tue, 28 May 2013 16:51:49 +0000 (UTC) Message-ID: <51A4E0C3.3040104@gentoo.org> Date: Tue, 28 May 2013 12:52:19 -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> In-Reply-To: <1369759349.3446.44.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: de4fb69e-e60f-41b6-af49-c6c083f9d4b3 X-Archives-Hash: 7c621f0ab67e9d1320a17ea1bf8ab7f5 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/28/2013 12:42 PM, Brian Dolbec wrote: > On Tue, 2013-05-28 at 00:34 -0400, Rick "Zero_Chaos" Farina wrote: >> It has come to light that this patch breaks binpkg use in stage1. > ... >> Thanks, >> Zero >> >> On 03/26/2013 11:09 PM, Jorge Manuel B. S. Vicetto (jmbsvicetto) wrote: >>> From: "Jorge Manuel B. S. Vicetto (jmbsvicetto)" >>> >>> + elif [ -n "${clst_PKGCACHE}" -a -z "${clst_update_seed}" ] > > As it turns out, this one change was incorrect to evaluate all possible > scenarios. My bash skills are poor, I originally had used nested if's , > but that got optimized by others to the above line. > > That line should be changed to: > > elif [ -n "${clst_PKGCACHE}" ] && ( [ -z "${clst_update_seed}" ] || [ "${clst_update_seed}" == "no" ] > > Which breaks down to (for those that can't follow it's logic): > > # NOTE: clst_update_seed is currently only used for a stage1, so does not exist in the environment for other targets. > # spacing was added to the line so it lines up with the plain English text. > > # if clst_PKGCACHE is not null and either clst_update_seed doesn't exist or clst_update_seed is exactly equal to "no" > #if [ -n "${clst_PKGCACHE}" ] && ( [ -z "${clst_update_seed}" ] || [ "${clst_update_seed}" == "no" ] ) > > > 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. > they are being set, but only --binpkg was being reset to =n in > the stage1-chroot.sh update_seed command. The other binpkg > options were not being removed or reset. This is poor coding. > It is far better to just not add the unwanted options in the > first place. > 2. While it is possible to work around not having the logic in > setup_myemergeoptions(), it is hacky and complicates the > stage1-chroot code more than neccessary. It is also poor > programming style. In total it would mean the > setup_myemergeoptions() would be called three times in total for > the stage1 run. Or temporarily saving the emerge options, > unsetting clst_PKGCACHE, re-running setup_myemergeoptions() to > get the correct options for update_seed, then later restoring > the the two variables correctly. Both these coding options are > poor programming style and more prone to bugs. With the > proposed change above it would be run twice. Once keeping the > PKGCACHE options off for the update_seed run, then reset > according to the spec for the target emerge run. > 3. Placing the clst_update_seed logic to toggle the PKGCACHE > options in the setup_myemergeoptions() simplifies the stage1 > code. Plus it leaves the option to run an update_seed > option/command for any future or current target without > complicating/duplicating code. > > I have attached a small test program I used to come up with the > correctly working patch change above. It can be used to evaluate how > the line's logic is processed. I have also attached the terminal output > it produced for all the possible conditions that could occur. > > 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 > > I will be pushing an updated rewrite branch with this and the other > changes made to master soon. So "git pull --force" to update your > checkout with the rewritten commits when I do. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpODDAAoJEKXdFCfdEflK51IP/0xZohUutpNMW+lpPKbkb7Kc /peVQGs1wgnHZcvHbEnJb9F04oK4IIdal7eOpOi/cNagD/37RojNvvfHexe7zFXP rhIoE/o++5Ma/iHjgHVY3EUk4mqdDKQMP9vht0g7TiAeNhjKa5bTAYeaq8vTBzCZ /X9PFlLyPirs6MEszz/dWP0xkFVXSD9QCr4jF4g2brQIXjav0+P7jVFgITME/atS H26F9tglDQeSZyM2mtTsbuzsPkHjau7Qkso7ITlyHNozore6M19hOLVLEXm9kfgq 8VDFq7rt8S3IsdkD85Xy8eIAw++wpFqMUiXubX1zCfa8qYPwf19yWWq4thQOt288 IRRtE/QGMaMi/V/rtoxnmQZEOHu8U5t5Uuw31DTNNmdVe1uRhs8WXdtbp/0ufFaG BOGjv2yRkvgKx4d6TZcpn1T/LPJS/bFBEZYpPEyHV1G8leYOJi8CyasYZBSF7v7A 7U4GgfQul85+uogYTgNZ4I6d5aRfc5/FMH7/zycyIeKbNlso5iBow0s+XIKhhc4l UYEyFirBNG55ZNIE18OxjQOCD2R9FjujwpJc1cuB20Hx93IRVifNIbcDZ6LaR5yq fSLR/nzJJj2L3kv7Uq88akQClpVQMRruXQhNI7mTfhCjWmQtyHVbyeS8kOyJultV yE4dIpKzkJ7OEuL4Dg0u =ogZD -----END PGP SIGNATURE-----