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 DB54C1381F3 for ; Tue, 28 May 2013 19:33:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7DD22E0A7F; Tue, 28 May 2013 19:33:41 +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 07C90E0A7F for ; Tue, 28 May 2013 19:33:40 +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 11D2E33DBAB for ; Tue, 28 May 2013 19:33:39 +0000 (UTC) Message-ID: <1369769617.3446.83.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 12:33:37 -0700 In-Reply-To: <51A4FC90.8000005@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> <1369763980.3446.71.camel@big_daddy.dol-sen.ca> <51A4FC90.8000005@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: 70fe29c6-bb96-41ba-a4ee-616c046efaf1 X-Archives-Hash: 85fb3e372cf1e64722d134214de489ae On Tue, 2013-05-28 at 14:50 -0400, Rick "Zero_Chaos" Farina wrote: > On 05/28/2013 01:59 PM, Brian Dolbec wrote: > > 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. > > I think you did a typo there. There are 2 portage options --rebuild-if-new-ver and --rebuild-if-new-rev. I opted for the *-ver (version), since most revisions would not need to trigger a rebuild. But the failure in that bug should be the same or similar fix to our needs. > 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 > > If someone wants to work on fixing it. The solution will require extracting the NEEDED.ELF.2 info from the binpkg and confirming that the links exist. If any of them don't, then trigger the build from source. Rejecting the existing binpkg. You may also want to talk to blueness, he created a utility for looking for broken elf links.