Portage appears to maintain a map from ebuild file content (and also eclass file content?) to cached Manifest files and to sometimes use that instead of the Manifest file in the tree when downloading and verifying URLs listed in SRC_URI.

This causes problems for  issue 856491 , where eclass/tast-bundle.eclass is setting SRC_URI dynamically based on the contents of chromeos-base/tast-local-tests-cros/files/external_data.conf. See https://crrev.com/c/1119609 for some discussion.

The problem is easy to demonstrate using tast-local-tests-cros:

a) add a new entry to chromeos-base/tast-local-tests-cros/files/external_data.conf
b) run "ebuild <path to tast-local-tests-cros-9999.ebuild> manifest" and see that chromeos-base/tast-local-tests-cros/Manifest doesn't get updated
c) add arbitrary whitespace to tast-local-tests-cros-9999.ebuild
d) run "ebuild ... manifest" again; new entry is added to Manifest
e) run "emerge-<board> tast-local-tests-cros"; new file is downloaded
f) remove whitespace from tast-local-tests-cros-9999.ebuild
g) run "emerge-<board> tast-local-tests-cros"; build fails due to missing new file now

So even though the Manifest file contains the new entries, emerge appears to ignore it if the ebuild file is the same as before.

Is this expected behavior from emerge? The documentation around "ebuild ... manifest" seems pretty thin, so I'm not sure.

Is there some way to convince emerge to use the current Manifest, maybe by running egencache? Even if there is, I'd be worried that things would still break in other developer's chroots.

If this is expected behavior, I can probably implement a workaround for tast-local-tests-cros (at the cost of a bit more duplication when making changes) such that the ebuild file will be changed whenever an entry is added.