[gentoo-catalyst] Binary package dependencies and update_seed

[W. Trevor King]

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 <wking@×××××××.us> 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