This documents describes methodology for removing support for 'N' amount of architectures for 'K' amount of packages that exists in Fedora.
Background
I hope this document will become universally applicable to the following scenario:
- There are 'K' packages, already released in Fedora, built for several architectures
- These 'K' packages provides 'L' names
- There are other packages that depend on any of these 'L' names provided by these 'K' packages and their 'M' sub-packages build-time, run-time or both
- You want to stop building those 'K' packages on 'N' architectures, but you want to make sure, all packages that depend on the 'K' packages will be properly taken care of
- 'K', 'L', 'M', 'N' are integers
- There will be at least one architecture left after you're done, and it is NOT 'noarch'
My original case
This is my original case, on which I'll demonstrate the whole process.
I maintain packages 'mariadb' and 'community-mysql' for which I wanted to drop support for the i686 architecture.
This was done as a part of this change proposal: "F40 MariaDB MySQL repackaging"
And the reason for dropping the architecture was saving maintainer time, energy and computational resources.
It´s based on this accepted change: "Encourage i686 Leaf Removal"
These package provide it's names, additional names, libraries, pkgconfigs, and so on.
A lot of other packages relies on them - as they are huge, well established databases - both build-time and run-time.
Part of the stack are database connectors to various languages, which I also maintain.
One such is 'mariadb-connector-c' which is special. It provides the client library for MariaDB and it's development files.
And since the MariaDB and MySQL are compatible - regarding the client side - this library can server for both.
I know a lot of very important packages relies on those databases, but I never kept track of how big is that dependency tree exactly.
RPM symbols
An RPM package can provide a lot of symbols. I´ll divide them to two categories: "names", and "other provides".
RPM "names" consist of names provided by the RPM - either implicitly (package name) or explicitly (names you specify with Provides: in the SPECfile).
RPM "other provides" consists of stuff like libraries, pkg-config files, and more.
You can check what an RPM package provides with rpm -q --provides <PATH_TO_RPM>
An example:
# rpm -q --provides mariadb-embedded-10.5.22-1.fc40.x86_64.rpm libmariadbd.so.19()(64bit) mariadb-embedded = 3:10.5.22-1.fc40 mariadb-embedded(x86-64) = 3:10.5.22-1.fc40 mysql-embedded = 3:10.5.22-1.fc40 mysql-embedded(x86-64) = 3:10.5.22-1.fc40
Other packages can depend on any of the symbols provided by your package.
So the first step has to be finding out, what all symbols your packages provide.
We will always start with Fedora Rawhide, to avoid regressions in our work, and then - if needed - move to the older releases.
Package repositories have web UI called Pagure in Fedora: https://src.fedoraproject.org/rpms/mariadb
On the front page of a given package you can see production builds both released and in testing (in BODHI).
Clicking on any such link will take you to the KOJI to the specific build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2295452
There you can see list of artifacts (RPM packages, logs, ...). Clicking on "info" link next to any package will bring you to the detail of the the RPM package: https://koji.fedoraproject.org/koji/rpminfo?rpmID=35996855
There you can see the symbols the package provides and requires.
However, we want to gather these data in an automated way.
See the get_rpm_symbols.py script I've created: https://gitlab.com/.../get_rpm_symbols.py
It will get you all the symbols all of the selected RPM packages provides in any of their sub-packages.
You can take a look at the STDOUT file containing copy of what the script produces on the standard output and the results_sorted file to see the results, with which we will work later.