Enable fetching packages from multiple comps groups for each desktop.
This is currently unused but this removes the constraints around having
all base packages for a given desktop in a single comps group.
This could also be used to get packages from other groups such as the
input-methods group for example.
This lets the recently-merged improved arch-specific package
support handle all the arch-specific packages which were
previously excluded in `comps-sync-exclude-list.yml` and listed
manually in `fedora-common-ostree.yaml`. As the diff shows,
the sync script now correctly includes the same packages for
the same arches in `fedora-common-ostree-pkgs.yaml`, plus a few
appropriate additions of things that should be there but had
been left out, on ppc64le and aarch64.
We also drop the `packages-armhfp` and `packages-ppc64` lists,
as we no longer build for either of those arches. This allows
us to move `ostree-grub2` into the non-arch-specific list, since
it's no longer left out on any arch we care about.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The rpm-ostree backend in Discover is now in a good shape and should be
ready for wider testing so let's enable it in Rawhide first and then we
will backport it to F37 once Plasma 5.27 lands there.
See: https://pagure.io/fedora-kde/SIG/issue/133
This reverts commit 82989adb2e.
This includes corrections for per-arch packages, thanks to the
improvements to comps-sync.py in the previous commit.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Bash Heredoc in inline YAML string is tricky. Use an independent
post-process script instead.
Fixes: 5bbc140 Revert "Revert "common: Add readonly sysroot migration unit and script""
Exclude rpm-ostree backend for Discover from the base image as it is
still not ready for general consumption.
This used to be enabled only in Rawhide but let's keep it out until it's
fixed as it's easily overlayed for debugging and testing.
Required to enable complex input-methods support. We might consider
including the input-methods comps group if it turns out that we need
more packages.
Fixes: https://pagure.io/fedora-kde/SIG/issue/156
This reverts commit 31ad6acced.
With the addition of the fedora-updates-archive repository to fedora-repos, our
concern about not being able to find the correct -devel packages to install
have disappeared. Additionally, the kernel now ships -matched versions
of its packages (to allow matching headers to the main kernel package)
and akmods depends on the matched package, which means that we are sure
to get the package we need.
See also: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1195
See also: https://src.fedoraproject.org/rpms/akmods/pull-request/3
