There are issues with the filesystem package in Mageia that lead to
unpredictable setup for the filesystem hierarchy when setting up
chroots. In order to work around this problem, let's create some
of the basic paths ourselves while we wait for the issue to be fixed.
Reference: https://bugs.mageia.org/show_bug.cgi?id=26044
Since Mageia 6, it has not been necessary to copy the qemu binaries
and the binfmt files into the chroot to run ARM binaries inside a chroot.
This change finally stops doing that.
In order to make sure this works properly, we ensure that systemd-binfmt
is restarted to apply binfmt changes on the system. This ensures that
the host qemu-user-static is configured to execute binaries, even in
chroots.
While Mageia does not yet produce DeltaRPMs, it would never make
sense to fetch them for building ARM images, so we just turn it off
pre-emptively to simplify things for the future.
Some mirrors have issues with ranged fetching of files, which is a
critical aspect of fetching zchunk-based repodata. In order to
to improve the reliability of fetching repodata and packages, disable
this.
We need distribution-gpg-keys to provide us the Mageia GPG key file
in the distribution-agnostic location. As this package is available
on virtually every distribution that also has DNF, it's easily relied
upon.
With self-contained configuration, the repository definitions
will be predictable based on the target architecture and avoid
leaking anything from the host.
This change makes it so that the ARM image creation script uses DNF
instead of urpmi. This affords several advantages:
1. Mageia images can be created from non-Mageia systems
2. Mageia images can be created from within Mock
3. ARM images can be created from x86_64 hosts
4. Image building can rely on pre-installed repo configurations
This also brings us in line with the Docker image creation process,
which also uses DNF.
Neal Gompa