This commit is contained in:
parent
c7dfa3ca1c
commit
f65d9889c2
GPG Key ID:
B37E62D143879B36
83
docs/legacy/debrand_list.md
Normal file
83
docs/legacy/debrand_list.md
Normal file
@ -0,0 +1,83 @@
|
|||||||
|
---
|
||||||
|
title: Rocky Debrand Packages List
|
||||||
|
---
|
||||||
|
|
||||||
|
This is a list of packages that require changes to their material for acceptance in Rocky Linux. Usually this means there is some text or images in the package that reference upstream trademarks, and these must be swapped out before we can distribute them.
|
||||||
|
|
||||||
|
The first items in this list are referenced from the excellent CentOS release notes here: https://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.1905#Packages_modified_by_CentOS
|
||||||
|
|
||||||
|
It is assumed that we will have to modify these same packages. It is also assumed that these changed packages might not necessarily be debranding.
|
||||||
|
|
||||||
|
However, this list is incomplete. For example, the package **Nginx** does not appear on the list, and still has RHEL branding in the CentOS repos. We will need to investigate the rest of the package set and find any more packages like this that we must modify.
|
||||||
|
|
||||||
|
One way to find said changes is to look for `?centos` tags in the SPEC file, while also looking at the manual debranding if there was any for the `c8` branches.
|
||||||
|
|
||||||
|
There will be cases where a search and replace for `?centos` to `?rocky` will be sufficient.
|
||||||
|
|
||||||
|
Current patches (for staging) are [here](https://git.rockylinux.org/staging/patch).
|
||||||
|
|
||||||
|
|
||||||
|
## Packages that need debranding changes:
|
||||||
|
|
||||||
|
| Package | Notes | Work Status |
|
||||||
|
|:--------|--------------|-------------------------|
|
||||||
|
| abrt | See [here](https://git.rockylinux.org/staging/patch/abrt) | **DONE** |
|
||||||
|
| anaconda | See [here](https://git.rockylinux.org/staging/patch/anaconda) | **DONE** |
|
||||||
|
| apache-commons-net | AppStream module with elevating branch names | NO CHANGES REQUIRED |
|
||||||
|
| ~~basesystem~~ | (does not require debranding, it is a skeleton package) | NO CHANGES REQUIRED |
|
||||||
|
| cloud-init | See [here](https://git.rockylinux.org/staging/patch/cloud-init) | **DONE** - NEEDS REVIEW IN GITLAB (Rich Alloway) |
|
||||||
|
| cockpit | See [here](https://git.rockylinux.org/staging/patch/cockpit) | **DONE** |
|
||||||
|
| ~~compat-glibc~~ | | NOT IN EL 8 |
|
||||||
|
| dhcp | See [here](https://git.rockylinux.org/staging/patch/dhcp) | **DONE**, NEEDS REVIEW IN GITLAB (Rich Alloway) |
|
||||||
|
| firefox | See [here](https://git.rockylinux.org/staging/patch/firefox) -- Still requires a distribution.ini ID | **MOSTLY DONE** (Louis) |
|
||||||
|
| fwupdate | | NOT STARTED |
|
||||||
|
| glusterfs | Changes don't appear to be required | NO CHANGES REQUIRED |
|
||||||
|
| gnome-settings-daemon | No changes required for now. | NO CHANGES REQUIRED |
|
||||||
|
| grub2 | (secureboot patches not done, just debrand) See [here](https://git.rockylinux.org/staging/patch/grub2) | **DONE**, NEEDS REVIEW IN GITLAB AND SECUREBOOT (Rich Alloway) |
|
||||||
|
| httpd | See [here](https://git.centos.org/rpms/httpd/c/2f74eecf85362e67c403b7b1386a729da3e5c33d?branch=c8-stream-2.4) | **DONE** |
|
||||||
|
| initial-setup | See [here](https://git.rockylinux.org/staging/patch/initial-setup) | **DONE** |
|
||||||
|
| ipa | This is a dual change: Logos and ipaplatform. Logos are taken care of in `rocky-logos` and the `ipaplatform` is taken care of here. See [here](https://git.rockylinux.org/staging/patch/ipa) | **DONE** |
|
||||||
|
| ~~kabi-yum-plugins~~ | | NOT IN EL 8 |
|
||||||
|
| kernel | See [here](https://git.centos.org/rpms/kernel/c/20287bd53a5c2e87db2470380271b72ac8a1ed59?branch=c8) for a potential example | NOT STARTED |
|
||||||
|
| ~~kde-settings~~ | | NOT IN EL 8 |
|
||||||
|
| libreport | See [here](https://git.rockylinux.org/staging/patch/libreport) | **DONE** |
|
||||||
|
| oscap-anaconda-addon | See [here](https://git.rockylinux.org/staging/patch/oscap-anaconda-addon) | **DONE** Requires install QA |
|
||||||
|
| PackageKit | See [here](https://git.rockylinux.org/staging/patch/PackageKit) | **DONE** |
|
||||||
|
| ~~pcs~~ | | NO CHANGES REQUIRED |
|
||||||
|
| plymouth | See [here](https://git.rockylinux.org/staging/patch/plymouth) | **DONE** |
|
||||||
|
| ~~redhat-lsb~~ | | NO CHANGES REQUIRED |
|
||||||
|
| redhat-rpm-config | See [here](https://git.rockylinux.org/staging/patch/redhat-rpm-config) | **DONE** |
|
||||||
|
| scap-security-guide | QA is likely required to test this package as it is | NO CHANGES REQUIRED, QA REQUIRED |
|
||||||
|
| shim | | NOT STARTED |
|
||||||
|
| shim-signed | | NOT STARTED |
|
||||||
|
| sos | See [here](https://git.rockylinux.org/staging/patch/sos) | **DONE** |
|
||||||
|
| subscription-manager | See [here](https://git.rockylinux.org/staging/patch/subscription-manager) | **DONE**, NEEDS REVIEW |
|
||||||
|
| ~~system-config-date~~ | | NOT IN EL8 |
|
||||||
|
| ~~system-config-kdump~~ | | NOT IN EL8 |
|
||||||
|
| thunderbird | See [here](https://git.rockylinux.org/staging/patch/thunderbird) | **DONE** |
|
||||||
|
| ~~xulrunner~~ | | NOT IN EL 8 |
|
||||||
|
| ~~yum~~ | | NO CHANGES REQUIRED |
|
||||||
|
| **(end of CentOS list)**
|
||||||
|
| nginx | Identified changes, in staging | (ALMOST) **DONE** |
|
||||||
|
|
||||||
|
## Packages that need to become other packages:
|
||||||
|
We will want to create our own versions of these packages. The full "lineage" is shown, from RHEL -> CentOS -> Rocky (Where applicable)
|
||||||
|
|
||||||
|
| Package | Notes |
|
||||||
|
|:--------|--------------|
|
||||||
|
| redhat-indexhtml -> centos-indexhtml -> rocky-indexhtml | [Here](https://git.rockylinux.org/original/rpms/rocky-indexhtml) |
|
||||||
|
| redhat-logos -> centos-logos -> rocky-logos | [Here](https://git.rockylinux.org/original/rpms/rocky-logos) |
|
||||||
|
| redhat-release-* -> centos-release -> rocky-release | [Here](https://git.rockylinux.org/original/rpms/rocky-release) |
|
||||||
|
| centos-backgrounds -> rocky-backgrounds | Provided by [logos](https://git.rockylinux.org/original/rpms/rocky-logos) |
|
||||||
|
| centos-linux-repos -> rocky-repos | [Here](https://git.rockylinux.org/original/rpms/rocky-repos) |
|
||||||
|
| centos-obsolete-packages | [Here](https://git.rockylinux.org/original/rpms/rocky-obsolete-packages) |
|
||||||
|
|
||||||
|
## Packages that Exist in RHEL, but not in CentOS
|
||||||
|
For sake of complete information, here is a list of packages that are in RHEL 8, but do not exist in CentOS 8. We do not need to worry about these packages:
|
||||||
|
|
||||||
|
- insights-client
|
||||||
|
- Red_Hat_Enterprise_Linux-Release_Notes-8-*
|
||||||
|
- redhat-access-gui
|
||||||
|
- redhat-bookmarks
|
||||||
|
- subscription-manager-migration
|
||||||
|
- subscription-manager-migration-data
|
||||||
5
docs/legacy/index.md
Normal file
5
docs/legacy/index.md
Normal file
@ -0,0 +1,5 @@
|
|||||||
|
---
|
||||||
|
title: Legacy
|
||||||
|
---
|
||||||
|
|
||||||
|
Legacy documentation comes here.
|
||||||
85
docs/legacy/koji_tagging.md
Normal file
85
docs/legacy/koji_tagging.md
Normal file
@ -0,0 +1,85 @@
|
|||||||
|
---
|
||||||
|
title: Koji Tagging Strategy
|
||||||
|
---
|
||||||
|
|
||||||
|
This document covers how the Rocky Linux Release Engineering Team handles the tagging for builds in Koji and how it affects the overall build process.
|
||||||
|
|
||||||
|
## Contact Information
|
||||||
|
| | |
|
||||||
|
| - | - |
|
||||||
|
| **Owner** | Release Engineering Team |
|
||||||
|
| **Email Contact** | releng@rockylinux.org |
|
||||||
|
| **Mattermost Contacts** | `@label` `@mustafa` `@neil` `@tgo` |
|
||||||
|
| **Mattermost Channels** | `~Development` |
|
||||||
|
|
||||||
|
## What is Koji?
|
||||||
|
|
||||||
|
Koji is the build system used for Rocky Linux, as well as CentOS, Fedora, and likely others. Red Hat is likely to use a variant of Koji called "brew" with similar functionality and usage. Koji uses mock, a common RPM building utility, to build RPMs in a chroot environment.
|
||||||
|
|
||||||
|
## Architecture of Koji
|
||||||
|
|
||||||
|
### Components
|
||||||
|
|
||||||
|
Koji comprises of multiple components:
|
||||||
|
|
||||||
|
* `koji-hub`, which is the center of all Koji operations. It runs XML-RPC and relies on other components to call it for actions. This piece will also talk to the database and is one component that has write access to the filesystem.
|
||||||
|
* `kojid`, which is the daemon that runs on the builder nodes. It's responsibility is to talk to the hub for actions in which it can or has to perform, for example, building an RPM or install images. But that is not all that it can do.
|
||||||
|
* `koji-web` is a set of scripts that provides the web interface that anyone can see at our [koji](https://kojidev.rockylinux.org).
|
||||||
|
* `koji` is the command line utility that is commonly used - It is a wrapper of the various API commands that can be called. In our environment, it requires a login via kerberos.
|
||||||
|
* `kojira` is a component that ensures repodata is updated among the build tags.
|
||||||
|
|
||||||
|
### Tags
|
||||||
|
|
||||||
|
Tags are the most important part of the koji ecosystem. With tags, you can have specific repository build roots for the entire distribution or just a simple subset of builds that should not polute the main build tags (for example, for SIGs where a package or two might be newer (or even older) than what's in BaseOS/AppStream.
|
||||||
|
|
||||||
|
Using tags, you can setup what is called "inheritance". So for example. You can have a tag named `dist-rocky8-build` but it happens to inherit `dist-rocky8-updates-build`, which will likely have a newer set of packages than the former. Inheritance, in a way, can be considered setting "dnf priorities" if you've done that before. Another way to look at it is "ordering" and "what comes first".
|
||||||
|
|
||||||
|
Targets call tags to send packages to build in, generally.
|
||||||
|
|
||||||
|
## Tag Strategy
|
||||||
|
|
||||||
|
The question that we get is "what's the difference between a build and an updates-build tag" - It's all about the inheritance. For example, let's take a look at `dist-rocky8-build`
|
||||||
|
|
||||||
|
```
|
||||||
|
dist-rocky8-build
|
||||||
|
el8
|
||||||
|
dist-rocky8
|
||||||
|
build-modules
|
||||||
|
. . .
|
||||||
|
```
|
||||||
|
|
||||||
|
In this tag, you can see that this build tag inherits el8 packages first, and then the packages in dist-rocky8, and then build-modules. This is where "base" packages start out at, generally and a lot of them won't be updated or even change with the lifecycle of the version.
|
||||||
|
|
||||||
|
```
|
||||||
|
dist-rocky8-updates-build
|
||||||
|
el8
|
||||||
|
dist-rocky8-updates
|
||||||
|
dist-rocky8
|
||||||
|
dist-rocky8-build
|
||||||
|
build-modules
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
This one is a bit different. Notice that it inherits el8 first, and then dist-rocky8-updates, which inherits dist-rocky8. And then it also pulls in dist-rocky8-build, the previous tag we were talking about. This tag is where updates for a minor release are sent to.
|
||||||
|
|
||||||
|
```
|
||||||
|
dist-rocky8_4-updates-build
|
||||||
|
el8_4
|
||||||
|
dist-rocky8-updates
|
||||||
|
dist-rocky8
|
||||||
|
dist-rocky8-build
|
||||||
|
el8
|
||||||
|
build-modules
|
||||||
|
```
|
||||||
|
|
||||||
|
Here's a more interesting one. Notice something? It's pretty similar to the last one, but see how it's named el8_4 instead? This is where updates during 8.4 are basically sent to and that's how they get tagged as `.el8_4` on the RPM's. The `el8_4` tag contains a build macros package that instructs the `%dist` tag to be set that way. When 8.5 comes out, we'll basically have the same setup.
|
||||||
|
|
||||||
|
At the end of the day, builds that happen in these updates-build tags get dropped in dist-rocky8-updates.
|
||||||
|
|
||||||
|
### What about modules?
|
||||||
|
|
||||||
|
Modules are a bit tricky. We generally don't touch how MBS does its tags or what's going on there. When builds are being done with the modules, they do end up using the el8 packages in some manner or form. The modules are separated entirely from the main tags though, so they don't polute the main tags. You don't want a situation where say, you build the latest ruby, but something builds off the default version of ruby provided in `el8` and now you're in trouble and get dnf filtering issues.
|
||||||
|
|
||||||
|
### How do we determine what is part of a compose?
|
||||||
|
|
||||||
|
There are special tags that have a `-compose` suffix. These tags are used as a way to pull down packages for repository building during the pungi process.
|
||||||
Loading…
Reference in New Issue
Block a user