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 B66AE198005 for ; Wed, 27 Feb 2013 03:23:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3AD00E0814; Wed, 27 Feb 2013 03:23:20 +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 59818E0814 for ; Wed, 27 Feb 2013 03:23:19 +0000 (UTC) Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mattst88) by smtp.gentoo.org (Postfix) with ESMTPSA id 7192633DCC0 for ; Wed, 27 Feb 2013 03:23:18 +0000 (UTC) Received: by mail-yh0-f53.google.com with SMTP id q3so14698yhf.40 for ; Tue, 26 Feb 2013 19:23:16 -0800 (PST) X-Received: by 10.236.148.164 with SMTP id v24mr474705yhj.116.1361935396716; Tue, 26 Feb 2013 19:23:16 -0800 (PST) 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 Received: by 10.100.59.14 with HTTP; Tue, 26 Feb 2013 19:22:56 -0800 (PST) In-Reply-To: <1361934235.3997.331.camel@big_daddy.dol-sen.ca> References: <1361895645.3997.269.camel@big_daddy.dol-sen.ca> <1361934235.3997.331.camel@big_daddy.dol-sen.ca> From: Matt Turner Date: Tue, 26 Feb 2013 19:22:56 -0800 Message-ID: Subject: Re: [gentoo-catalyst] patch, fix broken seed stage update To: gentoo-catalyst@lists.gentoo.org Cc: zmedico@gentoo.org, fuzzyray@gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: d84d5d88-c88a-45ad-b592-578d46069844 X-Archives-Hash: 3b9eb80515466a4d0fed0c3eea6ae612 On Tue, Feb 26, 2013 at 7:03 PM, Brian Dolbec wrote: > On Tue, 2013-02-26 at 18:37 -0800, Matt Turner wrote: >> On Tue, Feb 26, 2013 at 8:20 AM, Brian Dolbec wrote: >> > --- a/doc/catalyst-spec.5.txt >> > +++ b/doc/catalyst-spec.5.txt >> > @@ -138,9 +138,19 @@ it should update the seed stage or not (valid values: `yes no`). >> > *update_seed_command*:: >> > This is an optional command to pass to emerge for updating the seed >> > stage (example: `--update dev-libs/mpfr dev-libs/mpc dev-libs/gmp`) >> > -If not specified, catalyst will update gcc deps. >> > +If not specified, catalyst will update gcc's deps, and rebuild gcc if any of >> > +it's deps are updated with a new version. Even if it itself is not updated. >> > +This prevents gcc breakage when it's dependency lib sonames have changed. >> > This setting requires enabling update_seed. >> > >> > +*update_seed_system*:: >> > +This is an optional setting supported by stage1 to tell catalyst if >> > +it should update the seed's system packages or not (valid values: `yes no`). >> > +This is run after any update_seed_command, updating any remaining upgradable >> > +system packages. >> > +This setting requires enabling update_seed. >> >> I don't see any need for an update_seed_system option. If someone >> wants to run emerge @system then they can do: >> >> update_seed_command: --options @system >> > > Well, Jorge last night was saying he wanted -uDN1 @world, but settled > for what was done. > > Also if you look at my change for the default update_seed_command. If > that is just made to @system, the problem I had updating my seed, it > would still be broken. The problem was that mpc was updated which > changed sonames, so gcc had to be rebuilt or was broken. Just doing an > emerge -uDN1 @system would not have rebuilt gcc for the new mpc lib. > And most system pkgs can not use EAPI 5 subslots to prevent breakage. > > This way gcc will get properly updated, rebuilt if necessary, then if > the user wants, update remaining system pkgs. > > It's there, now, only a few lines of code, and for the reasons above, > not as easy to do it all in one command. We would have to change the > update_seed_command spec option from being a run_merge() to a bash > subshell command. In that way it can be as complex as the user desires. So from talking on IRC, it seems that the problem that led to this patch was that a binpkg of gcc linked against an old mpc was used during stage1, leading to a broken gcc in stage2. Stripping --usepkg makes sense for this purpose. Removing --buildpkg I'm not sure about. It seems to me that anything that is built during the seed-update should be okay to use for the stage1. Adding an option for updating @system still seems unnecessary.