I believe what happened here is that we've updated glibc and then we've upreved the bash ebuild.  So we're getting a bash binary prebuild which is built against glibc-2.11 but the user getting it hasn't completed the upgrade to glibc-2.11.  So the upgrade fails because the newer bash package gets installed prior to the actual glibc upgrade

(No comment was entered for this change.)

i would have thought that the build_packages' execution of setup_board would have made sure that the chroot env was up to date including pulling down latest glibc

Spoke to Richard and it seems that he still as host glibc-2.10. update_chroot should force glibc to get updated. Obviously bash got updated before glibc did here. How could that happen?

Downgrading to p2 because there's only 2 known cases and it can only affect old chroots.

Hmm, for some reason, I was under the impression that we update toolchain first, but we just sweep through the world.

I think we should explicitly update toolchain first directly in update_chroot.

hmm, well the depgraph could have been with setup_board that bash came before glibc.  this is because we have very few packages that depend on glibc (by design), so it would have been considered in parallel.

perhaps we have to add a dedicated emerge step, or specifically list virtual/libc, when we run emerge in setup_board ?

Updating the toolchain first in update_chroot would be totally reasonable. That's what we do now in make_chroot.

Alternatively, parallel_emerge itself could be smart enough to special case these packages and update them first in sequence. That would be a generally useful feature.

This is concerning the host toolchain, so it shouldn't be a problem with setup_board, only with the host update procedure which is centralised in the update_chroot script (and make_chroot for initial setup).

As for the solutions...

I personally think implanting features for this into portage is a wrong way to go, unless you mean some more generic feature with use cases well over simply putting forward three package updates, and such feature would probably be too big of a nuke for our small pile of rocks.

Also, this is a very cros-specific problem, the death of binaries on missing libc symbols happens because of prebuilt packages get ahead of each other and emerge in a different order than they did as source packages on the builder, so upstream won't run into this problem unless someone happens to be making extensive use of binary packages or digging in the middle of a mine field.

I'm not sure it would be possible to fix this by putting the right packages into the dependency tree without triggering a terminal amount of circular dependencies, in general inside @system the dependencies happen to be very a dense graph. Maybe add an implicit dependency of everything on virtual/libc, since that's going to be transitively true in 99% of cases of packages, but it sounds still like a hack.

Unless someone objects, I'll just put host toolchain update forward explicitly in update_choot, along with portage update. That makes perfect sense for more reasons than this bug.

i prefer just moving the toolchain update forward in the script

this is a general binpkg problem and not one that can be solved here i think.  portage itself needs to grow more introspection in binpkgs to evaluate what is safe.

Commit: 4748e87341e78fa6bc062f0a29f1a03e63500667
 Email: zbehan@chromium.org

update_chroot: update toolchain and portage first, also select gcc

BUG=chromium-os:21474
TEST=run the script, see my chroot being updated, cases below:
1) run normally, see the latest gcc being selected
2) run while having an older gcc manually selected, see no updates
3) set an invalid native profile, see it being fixed

Change-Id: Ic84187b8acf39fba11f2e39f36457e6f696ad7e4
Reviewed-on: http://gerrit.chromium.org/gerrit/9832
Tested-by: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Zdenek Behan <zbehan@chromium.org>

M	update_chroot

Not anymore.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)