#312 comps-sync.py: handle arch-dependent package specs (#311)
Merged by kevin. Opened by adamwill.
adamwill/workstation-ostree-config comps-sync-arch  into  main

Download 312.patch

comps allows for a package to be included in a group only on
specified arches, with a line like this:

  <packagereq arch="aarch64,x86_64" type="default">kio-gdrive</packagereq>

up till now, comps-sync.py effectively ignored this, treating
such a line exactly the same as this:

  <packagereq type="default">kio-gdrive</packagereq>

and attempting to include the package even when building on e.g.
ppc64le.

Solving this is unfortunately tricky due to exactly how libcomps
handles these arch restrictions. It does not expose the list of
arches as a property of each returned 'package' object when you
do a group search. Instead you're supposed to filter the group
search down to the arch(es) you are interested in, and it only
includes the appropriate packages for that arch. So all we can
do is run our queries multiple times, once for each arch we may
wish to build on, keep track of the results per arch as we go,
and do some fancy footwork to keep track of the mapping between
"archful" comps entries and the lists in the YAML files.

This PR also includes a sync run with the new script, which corrects a few existing incorrect entries, including one that prevents Kinoite from building at present and a couple that would prevent the LXQt- and Deepin-based builds from building.

@walters

Build succeeded.

rebased onto fa798595cf05afac440ae54a0922213f89fcf74e

Build succeeded.

Note, if we add s390x, we get a rather bigger diff. do we care about ostree-based desktops on s390x?

Oh, this rather assumes that the packages-(arch) syntax can be used in any of these YAML files, and whatever the heck is reading them (some bit of rpm-ostree?) will DTRT. If that's not the case I guess I wasted my day. :D

The packages-$arch is indeed implemented by rpm-ostree's build side.
I only skimmed this but it looks sane.

We could probably make comps-sync be something run by the build process that generates the manifest and avoid the manual syncs.

Bigger picture we definitely have too many declarative package formats, from comps to kickstarts to blueprints, rpm-ostree manifests etc.

It does feel like things could be improved there, yeah. For me these manifests are essentially duplicating the work of the %packages sections of kickstarts; the fedora-kickstarts do a similar job of taking the comps groups but tweaking them a bit for the target context (live image or ARM disk image, in those cases). But of course, the kickstart format is kinda tied to anaconda. I'm not sure what the best way to reduce duplication would be, really. It'd be a bit odd to start using kickstart files to build ostrees...

Pull-Request has been merged by kevin

Metadata