|
|
|
|
|
by gnufx
1429 days ago
|
|
I don't know how RHEL packages are built exactly, since I'm not an employee, but mock is what the Fedora infrastructure runs under koji for builds. I don't see how "a CI" can make the process "nearer to reproduceable builds", whatever that means. I'm not aware or serious efforts on reproducible builds for Fedora/EL, in contrast to Debian, though there has been talk of it. You obviously should never use rpmbuild for binary rpms outside a chroot. The Alma infrastructure appears to be in their github space, though I don't know anything about it. What's wrong with it? |
|
About `mock`, the problem is the ABI. If you don't build the packages in the "perfect" order, the ABI degrades over time. For example, some libraries might accidentally add something in the middle of a struct. The API is 100% compatible. It will also run without any warning, but all pointers in the application using the libraries provided by those packages will now have an offset. A boolean might now point to in integer or something like this. If you don't have the tooling to detect this and don't have the tooling to ensure you build packages in the right order (and rebuild when needed), then you will eventually get some of these problems. Mostly on point releases. To solve this, the "trivial" way is to follow the RHEL build ordering, which requires some tools. The "correct" way is to use `libabigail`, `libsolv`, `libdnf` and other binary tooling and keep track of these things.
There are more of these little papercuts left and right you get when you build a RHEL clone. You can always cut corners and manually build everything, but you will payback the time you save in outages. RedHat has the test suite, the clones only have a small part of it, they have to be extra careful.