I've had a lot of trouble around the caching of external_files.conf too, and would also love to see it go away since then people would only need to edit one file instead of two. :-)

> While we usually have two ebuild files per package (stable and unstable), we have only one files/ directory. This means that, when we make a change to files under files/ directory for the unstable build, it also affects the stable build.

that applies to every cros-workon package that puts files under files/.  that's why the bots, when they see changes to files/, will perform an uprev on it.  for local development, this is normal behavior ... if you're making changes to files/, you should be using `cros-workon start ...` so that you always build the 9999 version.

> often invisible due to Portage's cache

that's the ebuild global invariant metadata:
https://devmanual.gentoo.org/general-concepts/portage-cache/index.html

> Assuming cros_workon start is not used, this builds the stable build (in a dry run), and it passes.

that's the bug.  we've never supported this flow.  it probably has "just worked" for many packages, but it's never been supported.

> Portage has too much freedom. It's not designed for humans like me making errors.

people complain when `emerge` and related operations are slow to calculate dependencies.  the metadata cache is the only way we can provide reasonable performance.  making changes outside of the ebuild standard breaks the guarantees of the cache.

> > While we usually have two ebuild files per package (stable and unstable), we have only one files/ directory. This means that, when we make a change to files under files/ directory for the unstable build, it also affects the stable build.
> 
> that applies to every cros-workon package that puts files under files/.  that's why the bots, when they see changes to files/, will perform an uprev on it.  for local development, this is normal behavior ... if you're making changes to files/, you should be using `cros-workon start ...` so that you always build the 9999 version.

Thanks, I was not aware that changes to files/ also triggers uprev.

> > Assuming cros_workon start is not used, this builds the stable build (in a dry run), and it passes.
> 
> that's the bug.  we've never supported this flow.  it probably has "just worked" for many packages, but it's never been supported.

Do you mean by "the bug" that it should be supported but not yet?

Do you have any open bug for it, or documentation that refers the restriction?


> > Portage has too much freedom. It's not designed for humans like me making errors.
> 
> people complain when `emerge` and related operations are slow to calculate dependencies.  the metadata cache is the only way we can provide reasonable performance.  making changes outside of the ebuild standard breaks the guarantees of the cache.

Portage has too much freedom, and Chrome OS introduced huge and complex layers like cros-workon on top of it, so it's too difficult for humans to tell what kind of changes violates "the ebuild standard", that's the problem. I guess you're the only person who understands it precisely in the team.

> Do you mean by "the bug" that it should be supported but not yet?

i mean we have supported workflows for cros-workon ebuilds, and what you're describing is not one of them (making changes to a cros-workon ebuild, but not using `cros-workon start`).  i don't think this is a flow we need to support.

> ...

the frameworks on frameworks do produce a complex system that can sometimes be difficult to keep a grasp on.  the ebuild rules can be distilled down to:
only inherited eclasses and the ebuild file itself are tracked for changes.  anything changed outside of those files (like things under files/) are impossible for portage to precisely keep track of while maintaining performance.

i'm not against trying to find improvements/simplifications to the overall system of course.  but what looks like an easy answer can often have unintentional cascading side effects :/.

Maybe we don't need to work on this because crbug.com/900181 may remove references to external files from ebuilds entirely.

crbug.com/900181 will fix this issue.