On Tue, Feb 26, 2013 at 7:03 PM, Brian Dolbec <[email protected]> wrote: > On Tue, 2013-02-26 at 18:37 -0800, Matt Turner wrote: >> On Tue, Feb 26, 2013 at 8:20 AM, Brian Dolbec <[email protected]> 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.
