Basic scenario:
I have a package.
The package is released in all active Fedora releases.
There are other packages having various combinations of BuildRequires: and Requires: on that package.
The package builds for many architectures.
Now I want (or need) to drop support for one of the architectures.
How can I safely test the impact of dropping such architecture ?
My specific case is that I am trying to drop ix86 builds for ‘mariadb’ and ‘community-mysql’ packages, as announced here:
https://fedoraproject.org/wiki/Changes/F40_MariaDB_MySQL_repackaging
I’ve created a COPR repository.
The COPR has ix86 chroot to test the changes and x86_64 chroot for reference.
https://copr.fedorainfracloud.org/coprs/mschorm/F40_MariaDB_MySQL_repackaging/builds/
For every rebuild of my packages, I want to severely bump Epoch: so it’s easy to spot whether the dependent packages, re-built on top of my packages, builds and works fine with the correct versions of my packages.
So first, I’ve bumped Epoch: by 10 and rebuilt the current versions of my packages - the packages should be effectively the same, but the COPR rebuilt packages should take preference, since they have a higher Epoch: value, than the packages in the distro.
Then I rebuilt some packages to see if they work fine.
They did (since I have not dropped ix86 yet)
Then I wanted to simulate an abrupt drop of ix86 builds of my packages.
So I bumped Epoch: on my packages to 20 and rebuilt them with ExcludeArch: %{ix86}.
I found out, that the dependent packages, that has BuildRequires: on my packages just used the oldest ix86 version available of my packages.
So on one hand this wasn’t a good simulation what happens when the ix86 build vanish entirely, but it showed what will happen when the ix86 builds vanish in a Fedora release in which some previous ix86 builds of my packages exists (that’s the case of current Rawhide). The good thing is that I shouldn’t need to worry about this scenario (dependent packages regressing back to the oldest ix86 builds of my packages available) in production, since if I first deal with all of the dependent packages, there shouldn’t be any package left that would behave in such a way.
So now I wanted for the x86_64 builds of my packages to Obsolete: the ix86 builds.
Sadly I found that’s impossible:
https://bugzilla.redhat.com/show_bug.cgi?id=840613
So instead, I’ve created new meta-package meta-pkg-obsolete-i686 which will build for every architecture, and it’s only function is to obsolete all versions of my packages before the ix86 drop:
Name: meta-pkg-obsolete-i686
Version: 1
Release: 1%{?dist}
Summary: meta-pkg-obsolete-i686
License: MIT
URL: http://fedoraproject.org
Obsoletes: mariadb < 30:10.5.22
%description
xxx
%prep
%build
%install
%files
%changelog
* Sat Oct 21 2023 Michal Schorm <mschorm@redhat.com>
-
Then I added the BuildRequires: meta-pkg-obsolete-i686 to every dependent package.
That worked and so I found a package that FTBFSed on ix86 and thus is need of fixing.
So the question is:
Can I achieve this in some elegant way ?
(testing how dependent packages would react to an abrupt drop of a builds, of a package they depend on, for a specific architecture)
By the way, I’ve noticed, that the noarch packages are built for every architecture in COPR:
Build 6554074 in mschorm/F40_MariaDB_MySQL_repackaging
It doesn’t work the same way in KOJI:
mysqltuner-2.2.12-1.fc40 | Build Info | koji
But it makes me question how the noarch build process actually works.
If the noarch can be built on any architecture, how it is decided in KOJI, on which architecture it will build ?
And what if a noarch package has BuildRequires: on a package that is arch-specific, and the package build would succeed on one architecture but NOT another?
Either beacuse of a bug in the BuildRequired package, or because the BuildRequired does not build for a specific architecture at all?