Rethinking RPM architecture support

[pmatilai]

Every time there's a PR for a new architecture in rpm, I have the strongest urge to stick my head into the sand until the PR just goes away, from old age or whatever. This is because nine times out of ten, those PR's go awry one way or the other. Somebody's ARM improvement breaks ARM entirely for another, despite both of them being equally correct (or wrong), somebody wants to support a microarchitecture that nobody else cares about, and we are expected to have insights on them all to appropriately manage the mess. It's a strong sign that the rpm architecture abstraction is wrong. News to anybody? I doubt. What follows is what some might consider radical ideas in broad strokes with various corners cut, in part inspired by discussion in #1038 . Keep an open mind and don't think I have all this figured out, I don't. The idea is to provoke discussion on the topic. One explicit goal of mine is to put an end to the impossible "support arch X" PR's, but it should be a mere side-effect of doing things right.

1. Turn architecture and OS compatibility into dependencies. Rpm is not interested in how a binary is executed, it's job is just to track the requirements for executability. ISA is but a one requirement among many others, ditto with OS, and tracking them via dependencies is far more flexible and natural than separate special tags with some very special assembler-coded (really!) fubar. So whether executability of a given package is provided through qemu or physical hardware, it's all the same to rpm (depsolvers will care more though, and that needs to be supported somehow).
2. Ditto with micro-architectures: the OS uses HWCAP to deal with these, and so should we. Turn them into dependencies, one way or another.
3. Outsource the enumeration and naming to the compiler etc department which already knows it all: ELF tracks architecture and OS, we don't need to double those and invent our own. Humans will want to see names instead of numbers of course, but that's effectively pretty-printing.
4. Free the low-level dependency strings from arch-related markers, track the arch separately. So if package X requires libz.so.1 then it'll require that same string on all architectures, only the (numerical) architecture data will change. Querying human-readable output is again mostly just pretty-printing (which eg createrepo might need to do until taught to deal with the new stuff natively)
5. As dependencies are many-to-many relations and are tracked on per-file level in rpm, this allows cleanly handling multiple, arbitrary architectures in a single package. Whether one wants to do that is a whole other question, I simply see it that as an arbitrary limitation removed. Rpm does not currently prevent you from adding binaries for multiple architectures into one package either, it'll just be rather confused if you do.
6. At the end of the tunnel, RPMTAG_ARCH and RPMTAG_OS will cease to exist, and there will be only two kinds of packages: binary and source, with dependencies to express what's needed to run them. In reality, package filenames will likely still need to carry some further identifiers. Details 😆

[DemiMarie]

5. As dependencies are many-to-many relations and are tracked on per-file level in rpm, this allows cleanly handling multiple, arbitrary architectures in a single package. Whether one wants to do that is a whole other question, I simply see it that as an arbitrary limitation removed. Rpm does not currently prevent you from adding binaries for multiple architectures into one package either, it'll just be rather confused if you do.

I can think of good reasons for this: consider cross-compiler packages with associated libraries.

[pmatilai]

Indeed. Another possible use-case may be having a single rpmbuild (with a cross-compiler) produce binaries for multiple architectures, that you could package into one, or just split into sub-packages per arch.

Another special case is fat binaries supporting multiple architectures in one binary, which is a case I suppose we should handle too somehow.

[Conan-Kudo]

This would be awesome for me, as I've been plodding away at RPM on macOS for a few years now. With the ongoing architecture transition, once again it is necessary to produce universal binaries.

[Conan-Kudo]

And this reminds me, I need a way to create empty packages to fake those dependencies. I currently have a "base env" package that has lines like:

Provides: Framework(System)
Provides: libSystem.B.dylib
Provides: libSystem.dylib

[voxik]

I need a way to create empty packages to fake those dependencies.

https://github.com/xsuchy/create-fake-rpm

[Conan-Kudo]

I already have scripts for creating these now, but if we have arch colors and markers and all kinds of fancy stuff, I need a way to set those in empty RPMs representing the system stuff.

[ffesti]

I agree in that architecture handling should move into dependencies. I guess we need to write down the actual problem first. This allows us to determine what solution might actually work. There are multiple places where architecture comes in play. Here just the first I can think of:

• A binary or library being linked to another library
  • May be using a base architecture as we do with %_isa may be sufficient
• Choosing which binary can be executed on the current system (or a given - probably emulated - architecture)
  • This is currently done by package architecture of the packages and by collecting them into arch related repositories
  • For this to be done via Requires we'd need some system provides that reflect the current processor
  • This still doesn't work well with emulator and stuff that are not supported on the system itself
  • Even when those emulators would Provides capabilities we'd want to separate them from the system
  • Or do we want to have a way to order architectures - and though all Provides - on what we think in more important?
• Choosing which (sub) architecture to build a package / binary for
  • Package name goes in here - somehow...

[dralley]

Crazy idea: perhaps GPU architecture should be treated the same way?

Currently the CUDA and ROCm packages tend to be massive, and that's partly because they contain optimized code for nearly a dozen different generations of GPUs, all crammed into each package.

$ dnf info rocblas rocsparse rocsolver
Last metadata expiration check: 0:08:54 ago on Wed 06 Mar 2024 06:09:47 PM EST.
Installed Packages
Name         : rocblas
Version      : 6.0.0
Release      : 3.fc40
Architecture : x86_64
Size         : 6.7 G
Source       : rocblas-6.0.0-3.fc40.src.rpm
Repository   : @System
From repo    : fedora
Summary      : BLAS implementation for ROCm
URL          : https://github.com/ROCmSoftwarePlatform/rocBLAS
License      : MIT AND BSD-3-Clause
Description  : rocBLAS is the AMD library for Basic Linear Algebra Subprograms
             : (BLAS) on the ROCm platform. It is implemented in the HIP
             : programming language and optimized for AMD GPUs.

Name         : rocsolver
Version      : 6.0.0
Release      : 4.fc40
Architecture : x86_64
Size         : 2.2 G
Source       : rocsolver-6.0.0-4.fc40.src.rpm
Repository   : @System
From repo    : fedora
Summary      : Next generation LAPACK implementation for ROCm platform
URL          : https://github.com/ROCmSoftwarePlatform/rocSOLVER
License      : BSD-3-Clause AND BSD-2-Clause
Description  : rocSOLVER is a work-in-progress implementation of a subset
             : of LAPACK functionality on the ROCm platform.

Name         : rocsparse
Version      : 6.0.0
Release      : 3.fc40
Architecture : x86_64
Size         : 4.8 G
Source       : rocsparse-6.0.0-3.fc40.src.rpm
Repository   : @System
From repo    : fedora
Summary      : SPARSE implementation for ROCm
URL          : https://github.com/ROCmSoftwarePlatform/rocSPARSE
License      : MIT
Description  : rocSPARSE exposes a common interface that provides Basic
             : Linear Algebra Subroutines for sparse computation
             : implemented on top of AMD's Radeon Open eCosystem Platform
             : ROCm runtime and toolchains. rocSPARSE is created using
             : the HIP programming language and optimized for AMD's
             : latest discrete GPUs.

It would be nice if installing only the appropriate implementation for the system's current GPU could be streamlined.

Sorry if this is too ambitious for the discussion :) It just sounds like something that could benefit from the described approach.

[DemiMarie]

100% agree. That said, AMD really ought to go the Nvidia route of having an intermediate bytecode.