# Step-by-step process for forking & rebuild RHEL **URL:** \ **Category:** Documentation\ **Created:** [December 10, 2020, 3:03am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192 "2020-12-10T03:03:13Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![RNM](https://avatars.discourse-cdn.com/v4/letter/r/e9a140/32.png) [@RNM](https://forums.rockylinux.org/u/RNM)\ **Post date:** [December 10, 2020, 3:03am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/1 "2020-12-10T03:03:13Z")
Coming from [https://github.com/hpcng/rocky/issues/4](https://github.com/hpcng/rocky/issues/4) I also suggest Rocky Linux should have well and good documentation. As I notice currently many experience RH and CentOS developer come and join force to build Rocky Linux, which to me this is great time to document the technique for newcomers references ---
**Author:** ![robb](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/robb/32/148_2.png) [@robb](https://forums.rockylinux.org/u/robb)\ **Post date:** [December 10, 2020, 1:05pm UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/2 "2020-12-10T13:05:20Z")
Agree documentation is really important. At nethserver (centos based) we use readthedocs with the option to edit/add on github. This way this can be a true community effort, which idea I do like. ---
**Author:** ![boothb](https://avatars.discourse-cdn.com/v4/letter/b/9d8465/32.png) [@boothb](https://forums.rockylinux.org/u/boothb)\ **Post date:** [December 10, 2020, 1:34pm UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/3 "2020-12-10T13:34:07Z")
Good point. I guess the BSD manuals give a great high-level overview. There is a lot of more specific information in the CentOS wiki: > **[HowTos - CentOS Wiki](https://wiki.centos.org/HowTos)** And then there are probably resources from SL too… Would be great to gather and modernize this knowledge. Edit: This is very practical and useful: > **[About/Building\_8 - CentOS Wiki](https://wiki.centos.org/About/Building_8)** I like `No you can't just "sed s'/Red Hat/CentOS/' (someone always offers that) ` ---
**Author:** ![RNM](https://avatars.discourse-cdn.com/v4/letter/r/e9a140/32.png) [@RNM](https://forums.rockylinux.org/u/RNM)\ **Post date:** [December 11, 2020, 2:32am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/4 "2020-12-11T02:32:55Z")
The link you put is useful in general but not practical. We need more details step by step documentation ---
**Author:** ![pedroalvesbatista](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/pedroalvesbatista/32/176_2.png) [@pedroalvesbatista](https://forums.rockylinux.org/u/pedroalvesbatista)\ **Post date:** [December 11, 2020, 4:15am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/5 "2020-12-11T04:15:41Z")
What about we start designing the process of cloning some repo (CentOS for “fresh” start), building it, adding some scripting to advance the heavy duty, and then fetch packages to a local repo FTP server, and then the mirror. By the end, the complete bundle build of what would be Rocky. Thus, we start to do baby steps in sandbox and as a prize we got a reproducible cycle, with “do-break-learn-refactor-release” lean process to the score 😃 ---
**Author:** ![avmentzer](https://avatars.discourse-cdn.com/v4/letter/a/e79b87/32.png) [@avmentzer](https://forums.rockylinux.org/u/avmentzer)\ **Post date:** [December 12, 2020, 8:56pm UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/6 "2020-12-12T20:56:31Z")
Agree. Count me in for documentation(en,de). ---
**Author:** ![RNM](https://avatars.discourse-cdn.com/v4/letter/r/e9a140/32.png) [@RNM](https://forums.rockylinux.org/u/RNM)\ **Post date:** [December 13, 2020, 1:03am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/7 "2020-12-13T01:03:52Z")
Hi since you said count you for documentation then you should be know the steps. Could you post the “draft” here. Later on when wiki is up, we can put there. 😊 ---
**Author:** ![avmentzer](https://avatars.discourse-cdn.com/v4/letter/a/e79b87/32.png) [@avmentzer](https://forums.rockylinux.org/u/avmentzer)\ **Post date:** [December 13, 2020, 5:56am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/8 "2020-12-13T05:56:28Z")
Just in general 🙂 ---
**Author:** ![RNM](https://avatars.discourse-cdn.com/v4/letter/r/e9a140/32.png) [@RNM](https://forums.rockylinux.org/u/RNM)\ **Post date:** [December 15, 2020, 3:22am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/9 "2020-12-15T03:22:43Z")
Well since you know the general. Can you share here? Later on someone will extend and do corrections ---
**Author:** ![eva82414](https://avatars.discourse-cdn.com/v4/letter/e/b9bd4f/32.png) [@eva82414](https://forums.rockylinux.org/u/eva82414)\ **Post date:** [July 29, 2022, 6:37am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/10 "2022-07-29T06:37:50Z")
that’s sad that there is still nothing… ---
**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\ **Post date:** [July 29, 2022, 8:27am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/11 "2022-07-29T08:27:14Z")
This is quite the old topic… Unfortunately there’s no “step by step process” to doing a rebuild of RHEL. It unfortunately is not that simple nor cut and dry as there are too many variables and just too many moving parts. Ultimately what it comes down to for a project to make a rebuild is identifying what has to be done at a minimum and then building the foundation around it to do so, to allow the team to figure out what was missed or what can be done to improve the process. We generally know these to be true but not limited to: - Specific branded packages must be made (release, repos, gpg-keys, logos at a minimum) - Some packages have to be debranded - Some packages have to be changed to support Rocky (example, opa-ff, dotnet, osbuild, anaconda, grub2, kernel, and so on) - Red Hat specific logos and assets have to be swapped (eg stuff that does not show up in a logos package) - Packages must be built (usually in a bootstrap), and likely rebuilt to ensure consistency - Packages have a specific build order usually, and this is especially true during beta/minor release updates - UEFI/Secure Boot should be supported - All sources come from [git.centos.org](http://git.centos.org), as red hat uploads their sources there - dnf groups require “comps” and a general pungi config setup With a general baseline, it is then that the plan of action is set forth. It has to be determined, what build system will be used, or in the case of already having one, how will we automate the process? Let’s look at Rocky 8 for example. We followed most of what we could from our upstreams, CentOS Stream, Fedora, and RHEL and used koji. So we essentially needed at a minimum: - Koji, koji hub, koji builders - Sigul (key signing) - Module Build Service (for modularity builds, it’s an outside service) - An SCM (git) that holds all the spec and source files - Source tarballs will need a “look aside” or some sort of storage we can pull from Our koji setup is done via ansible and the playbooks are available in our (soon to be deprecated) [monorepo](https://github.com/rocky-linux/infrastructure). The roles are also in our organization. We then built automation around it with a tool called `srpmproc` to do imports, patching, and the like, as well as integrated it into koji as a wrapper to pull package sources. `distrobuild` was made as the automation around this though it is semi automated. `pungi` is then used to “compose” the repositories and images, to which we send off to our mirrors. For Rocky 9, we took what we learned and decided to do things a bit differently. The premise is the same with git and srpmproc, but now the build system, peridot, does all the building and composes for us, including assisting in image generation (like iso’s). It is then just a matter of doing a reposync to pull everything down and transfer to our mirrors. Most of what we do day to day, at a high and medium level is documented throughout our [wiki](https://wiki.rockylinux.org/team/release_engineering/). It’s not perfect. One of our engineers did have a blog series in the past that explained some of what was done and some know how of how we got to where we here [here](https://skip.linuxdn.org/blog.html#001_Rocky1_BuildSteps). In summary, there isn’t really a true step by step. There are guidelines and requirements laid out, and then the “plan” is built around those, starting from basic and usually ending up complex. ---
**Author:** ![brian](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/brian/32/5777_2.png) [@brian](https://forums.rockylinux.org/u/brian)\ **Post date:** [August 25, 2023, 3:43am UTC](https://forums.rockylinux.org/t/step-by-step-process-for-forking-rebuild-rhel/192/12 "2023-08-25T03:43:59Z")
Closed on August 25, 2023, 3:43am UTC