[Elv13]

Would you rather have `.rpm`s build by someone on the command line using `rpmbuild` or `mock` or something built by a CI with proper bootstraping and "nearer" to reproduceable builds. Also, by cutting corners on the CI, you risk introducing mild ABI problems which wont crash, but causes instabilities and potential security vulnerabilities. If they say they needed time to do it properly, I respect that.

[gnufx]

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?

[Elv13]

For the record, I am not saying something is wrong with Alma. I am saying if Rocky says they need time to get it right, then I see this as a good sign.

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.

[gnufx]

So, the claim is that RHEL has broken packaging which doesn't reflect ABI changes, and somehow that means you have to reverse engineer its build mechanism from srpms to accommodate it being non-deterministic somehow? Care to give an example? I don't remember ever seeing one. (Of course package maintainers for EPEL, for instance, should use abipkgdiff. I don't remember what the status of automating that is in Fedora.)

[awill]

>> I am saying if Rocky says they need time to get it right, then I see this as a good sign.

I've worked in software engineering for a long time. Sometimes delays are a good thing; A sign of waiting for quality. And sometimes they're a sign that things went wrong. That poor decisions were made, or implementation was slow due to junior people etc..

Interpreting 'need time to get this right' as a positive, and worse, as somehow a negative on Alma, who thrashed them to the finish line with an identical product, doesn't make sense.

[awill]

if that's the case, why in your example is someone running rpmbuild doing it so much faster than an automated CI system. If your reasoning is that it will be faster in the future. Fine. But I doubt it. Criticizing Alma because it was first sounds like FUD.