On Wed, 16 Dec 2020 at 06:46, aleksander.baranowski via CentOS-devel < centos-devel@centos.org> wrote:
Hi,
When it comes to modules the situation is clusterfu**.
That reason why making EL8 took us so long. I'm quite sure that without internal knowledge of modules (that only Fedora uses - and documentation sucks) amount of reverse engineering is tremendous. The best place to start is https://pagure.io/fm-orchestrator.
RHEL sources based/CentOS clones will also have different platform string, that will make the whole system reinstall itself xDDDDDDD. That's a reason why migrating to these solutions will be a pain in the neck.
Going back to src.rpms. If you are looking for src.rpms best bet is using original RHEL src.rpms, these are readily available when you have even minimal subscription. It's the much safer bet for long term system.
Imagine the following:
- RHEL made errata for package X version n release m.
- CentOS stream have package X version n release m+10.
Which one will be available on git.centos.org?
Both will be available on git.centos.org. All of the source code from RHEL-7 onward has been pushed to there... including buildroot only source code.
Using git.centos.org is a bad idea for next gen rebuilds IMO.
I am going to strongly recommend against this for 3 reasons:
- It is a contractual problem to do this. [AKA Get a lawyer. I am not one
and I am not going to try to argue it anymore than I am going to argue Rust language syntax I don't know. I will just say that two wrongs do not make a right.] 2. The src.rpms are not debranded. That is extra work a rebuilder has to do. The git source seems to be debranded by Red Hat. 3. Not all the src.rpms may be shipped with the developer etc. Red Hat Enterprise Linux 8 is not self-hosting. You need extra packages to build
That's an interesting point which is, from a technical POV, really not nice. Just imagine an enterprise Linux distribution which was a) self hosting, and b) provides reproducible builds...
Simon