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? Using git.centos.org is a bad idea for next gen rebuilds IMO. Bests, Alex On 12/16/20 12:13 PM, Stephen John Smoogen wrote: > > > On Wed, 16 Dec 2020 at 00:30, Thomas Stephen Lee <lee.iitb at gmail.com > <mailto:lee.iitb at gmail.com>> wrote: > > Hi, > > I am a grown-up kid :p. > > As a Christmas gift from CentOS, we would like CentOS core developers > to show us how they build a release from RedHat sources whenever > RedHat releases a version or an rpm. > > The documentation, scripts, and setup are what we are looking for. > > > https://github.com/centos <https://github.com/centos> has all the > ansible scripts used to set up the infrastructure. > https://git.centos.org/projects/centos/ > <https://git.centos.org/projects/centos/> contains most of everything else. > https://wiki.centos.org/QaWiki/AutomatedTests/WritingTests/t_functional > <https://wiki.centos.org/QaWiki/AutomatedTests/WritingTests/t_functional> > > Also on the wiki are a trove of various snippets of documents etc. > > > Now for documentation.. I don't think there is anything beyond that and > has never been. Each person knows their job and does it. When they go > out on break.. things tend to slow down for a reason. Making a cloned > operating system usually requires a lot of concentration on why did it > break this time when you did exactly all the same voodoo you did last > time.. > > From my own study, basically you need to reinvent via guesswork what was > done inside Red Hat step by step. Did they have to compile rust1 then > rust2 then rust3 to get thunderbird to work? Did they have to compile > rust3 then rust1 then rust2 then rust3? Or some other combinatoric list. > > Then we have modularity.. which tells you all that in its yaml files but > needs an entire special infrastructure to do it. > > > > > This is not for me personally, but for people interested in cloning > CentOS. > > Christmas cheers :) > > Thanks > > --- > Lee > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org <mailto:CentOS-devel at centos.org> > https://lists.centos.org/mailman/listinfo/centos-devel > <https://lists.centos.org/mailman/listinfo/centos-devel> > > > > -- > Stephen J Smoogen. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel >