Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/22b10f67d06d4d55b92e7da3dafc01a5

• validate : SUCCESS in 13m 49s

I'm struggling to understand how the change to comps-sync.py is solving the problem noted in the issue trackers.

Could you provide a pkg diff showing which new packages were added as part of this change?

@miabbott it adds an additional loop to the logic that gets packages from the comps workstation-product-environment env group, including the packages from option_ids (optional groups) as well as the packages from group_ids (mandatory groups). The resulting change to included packages is shown in the diff to fedora-common-ostree-pkgs.yaml, the added lines are the added packages. Ultimately this happens to result in, only, adding domain-client to the set of package groups included in all manifests produced by this tool.

Still, this does just 'feel' a bit wrong. I guess the wrongness is not added but baked in and historical; it's the way we start this whole group selection process by just unconditionally pulling in the groups from workstation-product-environment, even if we're not generating the groups for Silverblue. This is obviously because this repo started out only being for Silverblue. So we have exclude_list_groups, a kinda special-purpose exclude which is only applied when parsing workstation-product-environment and says "actually, don't include all these groups"...

So what we wind up doing, as the base for all atomic desktop images, is: "pull in the groups from w-p-e, that's container-management, core, desktop-accessibility, firefox, fonts, gnome-desktop, guest-desktop-agents, hardware-support, libreoffice, multimedia, networkmanager-submodules, printing, and workstation-product, only leave out libreoffice, gnome-desktop, container-management, and base-x". It's just a bit weird. It's essentially a hack to try and convert workstation-product-environment into a 'generic' list of appropriate groups for a desktop environment.

This PR makes it instead "pull in the groups and optional groups from w-p-e, that's container-management, core, desktop-accessibility, firefox, fonts, gnome-desktop, gnome-desktop-agents, hardware-support, libreoffice, multimedia, networkmanager-submodules, printing, workstation-product, arm-tools, domain-client, and base-x, only leave out libreoffice, gnome-desktop, container-management, base-x, and arm-tools"...so I guess it's not really more weird than before, it just reminds us of the weirdness.

Given the limitations of comps, it may be hard to come up with anything better than this which isn't just a hardcoded group list (which we then have to keep in sync with w-p-e manually, I guess). Ideally we'd have a 'generic' environment group which workstation-product-environment included, but you can't nest env groups like that in comps :(

Thanks for the detailed explanation, Adam!

Thanks Adam for the longer explanation!

As far as I know, Fedora Workstation does not use the generic comps groups that are used by the other Spins as the Fedora Workstation Working Group prefers maintaining their own.

Overall it does not matter much exactly which group we use. We only need something to keep package lists in sync and updated.

As far as I know, Fedora Workstation does not use the generic comps groups that are used by the other Spins as the Fedora Workstation Working Group prefers maintaining their own.

Not quite sure what you mean by that...probably going too far into the weeds here, but...comps kinda has two defined levels: the "group" and the "environment group". "groups" contain packages (mandatory, default or optional), "environment groups" contain groups (two lists: "grouplist" groups are mandatory parts of that environment, "optionlist" groups are optional and can be specified as default=true meaning they're selected by default in the installer but can be unselected). "groups" cannot contain other groups, "environment groups" cannot contain other environment groups or directly contain packages.

workstation-product-environment is the environment group for Workstation. There are plenty of other environment groups, e.g. kde-desktop-environment is the equivalent for Plasma/KDE. There's quite a lot of commonality between all the desktop groups - they mostly tend to have core, fonts, guest-desktop-agents, multimedia, networkmanager-submodules, and printing, for instance.

What you may be referring to is that workstation-product-environment, unusually, does not contain the 'standard' group (because they think it has too much stuff in it). Every other desktop env group does contain 'standard', but workstation chooses to only include 'core'.

If comps allowed more flexibility we could cut down on a lot of repetition and odd-and-probably-unintended differences in various configurations, but it doesn't. :|

it occurs to me we already have a transformation stage for comps files (from .xml.in to .xml) and we could maybe wedge some kind of 'include' mechanism into that, which would be interesting. probably something to discuss in a comps ticket, though.

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/6358ec11a4c448d1878c442dcde2d387

• validate : SUCCESS in 12m 27s

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/469556f3dcee42808433438e240001c6

• validate : SUCCESS in 12m 33s

Moved to https://forge.fedoraproject.org/atomic-desktops/config/pulls/504