On Debian, debootstrap has the --foreign and --second-stage options. This allows you to split the bootstrap process into two stages. Normally to make a system root filesystem you just run: # debootstrap ... However, when building a a filesystem for a foreign architecture (ie aarch64 from x64_64), you instead run: # debootstrap --foreign ... This command will download all the packages and unpack them in the specified directory. Once this is complete, you run: # chroot $root /debootstrap/debootstrap --second-stage This second stage will run any of the scripts specified in the packages. The key point is that in between these two stages, qemu-static binaries can be copied into the root to emulate the new architecture. dnf should support something like this.
first stage: you can install packages to specific dir by setting `--installroot=/path/`. second stage: you can fake architecture which DNF thinks is installed by setting $basearch variable in dnf.conf or from DNF Python API. Everything can by done in one DNF step.
Please can you provide an use-case in more detail to better understand how important is your request?
This is identical to what I was describing in devel@ recently[1]. Essentially, the missing piece is support for defining rootfs arch and triggering the usage of qemu-user-static so that scripts and stuff run correctly to build the rootfs sanely for a foreign architecture. Also, in this mode, it needs to download the very bare minimum needed to execute *itself* (or microdnf maybe) within the rootfs to complete the second stage. The first stage must run no scriptlets, and the second stage must run scriptlets using the target architecture emulator. Richard W.M. Jones actually gave an excellent summary of the multitude of advantages of having this functionality[2]. [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AIDUL7O4CJPIZB763N444KTKM63JNE5L/ [2]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQXD477WEIUG4VKMBD2BS2OTQS5NHUEG/
(In reply to Jaroslav Mracek from comment #2) > Please can you provide an use-case in more detail to better understand how > important is your request? The most significant use case is creating a non-x86_64 container which runs on x86_64.
(In reply to Honza Silhan from comment #1) > first stage: > you can install packages to specific dir by setting `--installroot=/path/`. > > second stage: > you can fake architecture which DNF thinks is installed by setting $basearch > variable in dnf.conf or from DNF Python API. > > > Everything can by done in one DNF step. Faking the architecture as you have proposed means that the binaries which are downloaded and unpacked will be correct. But running the rpm scriptlets will fail because you aren't on the native architecture. This is precisely why it needs to be divided into two stages. The first stage unpacks the rpms into the install root. In between the first and second stage the user prepares the install root for emulation (usually via statically compiled qemu binaries). The second stage runs all the rpm scriptlets (now emulated).
This is obviously nice and so on, but patches are welcomed. This is big task and it is definitely not focus for DNF team.
It might be possible by downloading qemu-user-static from the host architecture manually and installing without dependencies in the chroot followed by kicking off dnf with --installroot. However, there does not appear to be any way to set basearch (at least from the command line). Using --setopt=basearch=armv7hl throws a warning ("Main config did not have a basearch attr. before setopt") twice and then proceeds to install using the host architecture.
So, Nathaniel has posted a PR to resolve this: https://github.com/rpm-software-management/dnf/pull/866
The patch was released in dnf-2.6.3-1