RFE: Decouple build, host, and target platforms to enable cross-compiling RPM and RPMs #2020
Conan-Kudo
started this conversation in
Ideas
Replies: 2 comments
-
We've done some work on this with rpm5@cooker in the past, after encouragement of @Conan-Kudo, I might just sanitize, commit and make a pull request for it.. ;) https://github.com/OpenMandrivaAssociation/rpm/blob/master/rpm-5.4.15-crosscompile.patch |
Beta Was this translation helpful? Give feedback.
0 replies
-
This needs to be reviewed in the context of the architecture redesign whenever that happens. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Today, RPM implicitly ties the build and host+target together, meaning that every build is assumed to be a native build. However, this means that a few desirable use cases are difficult to do with RPM:
Making packages to target a foreign architecture: This is the main cross-compilation case. This is increasingly important for cases like bootstrapping a new architecture for a distribution (as Fedora is currently doing for MIPS and RISC-V), but also for making it easier for software developers to be able to build for a target platform that may not necessarily be a desirable host to build the software on. This is usually the case for people trying to build software for ARM SBCs (like the Raspberry Pi family, most notably, but also many of the MCUs used for the IoT space).
Making packages to target a foreign operating system: Another variant of the cross-compilation case, this is the case with the Fedora/Mageia MinGW toolchain. Because RPM makes this assumption, the packages have to be built as noarch and then a lot of behavior has to be overridden through macros in the spec file (dependency generation, debuginfo subpackage generation, etc.). This also makes it impossible to reuse the same spec to build both native package and MinGW subpackage variants. In many cases, the sources and patches are duplicates of the original, native one, which makes it even more wasteful. The loss of architecture information also means that it's not really easy to tie things together by the platform, because that information is not encoded in the RPM itself.
Making packages to bootstrap a foreign platform: If, for example, I want to build RPM and packages on x86_64 Linux to build Darwin or Minoca OS packages to build images of RPM-enabled Darwin or Minoca, that is currently very difficult, if not impossible. Technically, this is a fusion of the first two cases earlier, but it's common for things like Yocto/OpenEmbedded or other similar platforms.
Beta Was this translation helpful? Give feedback.
All reactions