This is kinda moot now. The only remaining diff here is what users belong to what groups, and we cannot really unify that as long as we have some xorg users (like lakitu).
The *user* baseline has been unified already. The only difference is that certain groups have different members on freon/non-freon.
So, if the suggestion is to make Freon the "default" and then overriding those groups in the test with the X11 baseline, that would probably be fine.
Summary: merge project-freon overlay into the main overlay (was: Merge Freon users into the main overlay)
i mean project-freon/ shouldn't exist at all. the fact that it does requires people to type "freon" in a lot of places now.
when i saw "users" i wasn't thinking "unix accounts". lemme relabel to clarify.
I am confused how this is meant to be achieved without losing some of the configs.
As I'm understanding overlay inheritance, if this is merged directly into the chromiumos base profile, the package.use and make.defaults would be applied to every board, and the group configs would be lost due to be overwritten by the eclass-overlay. This seems like kind of the worst case, because they'd each have part of what they originally had, but neither would be quite right.
I think the closest option I've come up with is to basically make a chromiumos freon profile that the freon boards use. That could easily replace the existing chromiumos parents by just extending the existing hierarchies to include a freon layer on top of the parent profiles they currently use. The parents files never list eclass-overlay as far as I have seen, so there's no inheritance chain to follow there, but the layout.conf masters lists are all "... chromiumos eclass-overlay ...".
How would the inheritance work in this case? Would the eclass-overlay group configs still overwrite the profile group configs? i.e. do the project-freon group config overrides work only because freon is listed after eclass-overlay in the masters list in each freon-based board's layout.conf?
I believe the group config overwriting could be addressed by just having the non-freon based group configs in the base profile, so the freon profile usage would overwrite the base. I sort of feel like splitting out the group configs from the eclass-overlay like that is getting to be kind of messy, though, so perhaps an eclass-overlay profile would be more appropriate? If so, where would be the preferred inheritance point for it - chromiumos profiles or in the boards?
I also feel like all of this is approaching a somewhat higher level of complexity than was implied by the short conversation above, is there something simpler for putting this all together that I missed?
you are correct that we lose the ability to support X builds directly anymore. that's OK -- we've already dropped the X server and have no plans to bring it back. there's also no reason to when people can use Wayland/Weston/XWayland to provide backwards compat for X projects.
that means that the input/tty/video groups that exist in eclass-overlay/ are unused. so replacing them with the accounts that exist in the freon overlay is what we want.
similarly for merging project-freon/profiles/{packages.use,make.defaults} into chromiumos-overlay/profiles/targets/chromeos/ ... we clobber/change some settings in there, but that's fine because the non-freon builds aren't tested or supported anymore.
Comment 1 Deleted