On Sat, Mar 09, 2013 at 07:10:23AM -0500, W. Trevor King wrote: > On Fri, Mar 08, 2013 at 12:14:08PM -0800, Matt Turner wrote: > > On Fri, Mar 8, 2013 at 10:47 AM, W. Trevor King wrote: > > > The earlier update_seed > > > command was not catching the bumped mpc, so add: > > > > I think this is a false premise. If it is true, we should understand > > why and fix it. The current command is emerge --onlydeps gcc which > > should be completely sufficient to update mpc. > > Using catalyst as of d1c2ba9b (create-iso.sh: add usb boot via > isohybrid, 2013-03-05), I can no longer reproduce my original problem. Ben Kohler (iamben) was working through this problem on #gentoo-releng recently. His problem (and probably my original problem as well) seems to be leftover binary packages from before update_seed was enabled. These binary packages matched the version number and USE flags of the to-be-installed package, but were built against the older version of mpc. In order to avoid problems like this, it's probably a good idea to remove all the cached stuff with something like [1]: $ rm -rf --one-file-system /var/tmp/catalyst/{kerncache,packages,tmp} before building your stage1. A better approach would involve recording runtime dependency versions in the binary package metadata, so that Portage could determine whether a given binary package would work in the target system [2]. Currently, the ebuild RDEPEND is included in Packages, but that does not always (or even often) specify which package versions were used to build the package. For example, sys-devel/gcc lists: RDEPEND: sys-libs/zlib virtual/libiconv >=dev-libs/gmp-4.3.2 >=dev-libs/mpfr-2.4.2 >=dev-libs/mpc-0.8.1 I'd like it to list: RDEPEND: =sys-libs/zlib-1.2.7 =virtual/libiconv-0 =dev-libs/gmp-5.0.2_p1 =dev-libs/mpfr-3.1.1 =dev-libs/mpc-1.0.1 or whatever the versions of those packages were at build time. Portage could then recurse through this information and only use the package if versions matched the target system across the whole RDEPEND tree. With ABI sub-slots, strict version matching could be loosened to only require ABI matching. Cheers, Trevor [1]: kerncache probably doesn't matter, but we might as well be thorough. [2]: This is a limitation with the current Portage code, and not a catalyst issue. Maybe I should cross-post this to gentoo-portage-dev@? -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy