The EasyApache 4 Git Repository and Build Updates
Last modified: August 28, 2019
This document explains how the EasyApache 4 build process works and how you can receive updates when we update the Git™ repositories.
EasyApache 4 repositories
EasyApache 4 uses many Git repositories, which each include master and production branches.
- The production branch is the primary branch and contains changes that we push to the public and are ready to use.
- The master branch provides a preview of upcoming releases and is useful to integrators who require time to adjust their own products.
When we merge a change into either the master or production branch of an EasyApache 4 repository, the system builds the change into an RPM. When the RPM builds successfully, the system then pushes the branch upstream into the corresponding branch in the GitHub® repository. The system then sends a notification of the change to the mailing list that corresponds with the changed branch.
EasyApache 4 build notifications
We send notifications when we make changes to the EasyApache 4 repositories. The emails contain the following information:
- The commit message or messages.
- The updated package with a shortened SHA.
To receive notifications when we update a repository, subscribe to one of our notification mailing lists.
Master — This list reports any changes to the master branch. These changes are not ready for public use.
Production — This list reports any changes to the production branch.
These mailing lists generate a large amount of traffic. The Subscribe link in the table above will subscribe you to the digest by default. We strongly recommend that you keep the list in digest mode.
Build an EasyApache 4 RPM
Only attempt to create your own RPM if you are an experienced system administrator. An incorrect configuration can cause your system to become unstable.
We do not provide support for custom RPMs or provide instructions on how to build them.
EasyApache 4 allows the ability to build your own RPMs for the system. Most users will not build their own RPMs, but if you require a custom configuration, you can use this option.
After you customize an RPM, you can build it with one of the following tools:
You can also build your RPMs with the source RPMs that our OBS repository provides. We strongly recommend that you only use the GitHub RPMs.
After you successfully build and package your RPM or SCL, upload it to your own repository. For more information, read our Yellowdog Updater, Modified (yum) Basics documentation.
You must package any PHP or other language RPM as a Software Collection (SCL) You cannot create an Apache collection as a Software Collection.
An SCL is an alternate path inside the
/opt file that contains the full file system that various software requires. When you enable an SCL, it adds the path within that environment to the system. The following situations use this path to determine the correct software version:
- Commands that do not specify a path.
- Scripts that use the
/usr/bin/envfile to determine their path.
In cPanel & WHM version 64 or earlier, all EasyApache 4 packages must begin with the ea- prefix.
In cPanel & WHM version 66 and later, EasyApache 4’s MultiPHP system recognizes SCL PHP packages with prefixes other than
ea-. This allows the use of vendor-provided packages. Read our PHP Home documentation for more information about potential issues with vendor-provided PHP versions.
You cannot use a prefix other than
ea- with any package other than an SCL PHP package.
The Software Collection standard determines the rest of the name. We strongly recommend that you use the same naming convention for Apache packages.
Implement a whole stack
If you wish to implement the whole stack with your repository, you must adhere to the following restrictions:
Do not modify or remove the
ea-profiles-cpanelpackage. EasyApache 4 requires this package to function.
You must name your packages with the
vendorrepresents the vendor’s name.
The package must install your profiles in the
vendornamerepresents the vendor’s name.