New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 819503 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

parallel_emerge rebuilds packages in the build-time depgraph in the wrong order

Project Member Reported by jclinton@chromium.org, Mar 7 2018

Issue description

From a build failure on the Fizz project during firmware upgrade: 

  https://chrome-internal-review.googlesource.com/c/chromeos/overlays/baseboard-fizz-private/+/581413

the build failed in during build_packages even though the CL's involved are correct.

For background, the chromeos-config-bsp ebuilds install config fragments and then the chromeos-config package compiles them together into the final configuration. In the case of Fizz, the order of package build should be:

  chromeos-config-bsp-baseboard, chromeos-config-bsp, chromeos-config, chomeos-firmware-fizz
Looking at the log we see:

[ebuild     U  ] chromeos-base/chromeos-config-bsp-baseboard-0.0.1-r3:0/chromeos-config-bsp-baseboard-0.0.1-r3::baseboard-fizz-private [0.0.1-r1:0/chromeos-config-bsp-baseboard-0.0.1-r1::baseboard-fizz-private] ...
[ebuild  r  U  ] chromeos-base/chromeos-config-bsp-0.0.1-r37:0/chromeos-config-bsp-0.0.1-r37::fizz-private [0.0.1-r36:0/chromeos-config-bsp-0.0.1-r36::fizz-private] ...
...
[binary  rR    ] chromeos-base/chromeos-config-0.0.1-r12::chromiumos ...
[ebuild     U  ] chromeos-base/chromeos-firmware-fizz-0.0.1-r120::fizz-private [0.0.1-r119::fizz-private] ...

So, all packages are being updated or rebuilt as expected.

However, in the logs we see this execution order:

chromeos-config
chromeos-config-bsp-baseboard
chromeos-config-bsp
chromeos-firmware-fizz

Because chromeos-config is installed before the change in chromeos-config-bsp-baseboard, the resulting compiled configuration is stale. So, when chromeos-firmware-fizz goes to get the name of the file it needs, the configuration has the old name.

What's particular puzzling is that all of the build-time deps (DEPEND=) are declared as they should be:

chromeos-firmware-fizz -> chromeos-config -> chromeos-config-bsp -> chromeos-config-bsp-baseboard

What's likely happened here is that parallel_emerge (not Portage) has applied an optimization to the order because it doesn't see any difference between the versions of the BSP packages from the perspective of the dependency graph. I don't agree that it should be considered correct: all build-time deps that are being rebuilt should be finished before starting a package build.

 
Cc: vapier@chromium.org
Components: -Build OS>Packages
Cc: dnojiri@chromium.org
Components: Infra>Client>ChromeOS>Build
Owner: ----
Status: Available (was: Assigned)

Sign in to add a comment