skip/SIG-FastTrack
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed open questions, added repo information

Browse Source
This commit is contained in:
Skip Grube 2023-08-07 02:58:04 +00:00
parent f6c0b5406b
commit 5ca3ee8f3f
1 changed files with 17 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
README.md
View File

@ -1,4 +1,6 @@
# Rocky Linux SIG/FastTrack # Rocky Linux SIG/FastTrack
### An RPM bazaar, not an RPM cathedral
SIG-FastTrack is a place for new packages and enhancements/upgrades to existing Rocky packages. To end-users, it will be 2 "no warranty, you break it you buy it" repositories that can be enabled to enhance their Rocky Linux installs with new and updated packages. This is a great way to provide optional much-needed functionality for Rocky users, while not interfering with the core distro's compatibility promises. SIG-FastTrack is a place for new packages and enhancements/upgrades to existing Rocky packages. To end-users, it will be 2 "no warranty, you break it you buy it" repositories that can be enabled to enhance their Rocky Linux installs with new and updated packages. This is a great way to provide optional much-needed functionality for Rocky users, while not interfering with the core distro's compatibility promises.
@ -11,17 +13,18 @@ Having said that, we can't have absolute anarchy. There must be some kind of a
### Possible Reasons a Package Cannot be Added to FastTrack: ### Possible Reasons a Package Cannot be Added to FastTrack:
- **It breaks or conflicts with the existing Rocky Repositories**. The FastTrack repos may provide RHEL-incompatible packages and updates, but they should never break DNF. If a user gets dependency or other DNF errors by running `dnf update` or `dnf install` , then the FastTrack package must be pulled or fixed. - **It breaks or conflicts with the existing Rocky Repositories**. The FastTrack repos may provide RHEL-incompatible packages and updates, but they should never break DNF. If a user gets dependency or other DNF errors by running `dnf update` or `dnf install` , then the FastTrack package must be pulled or fixed.
- **It changes a "core functionality" package in a questionable way, especially security-related.** The definition of "core" package here is a judgment call made by SIG leadership. These are things like OpenSSL, OpenSSH, nss, glibc, rpm, etc. We don't want to put users at risk by warping the way their Rocky system works and introducing issues. It may be possible to work around this by introducing an *additional* non-conflicting package version. - **It changes a "core functionality" package in a questionable way, especially security-related.** The definition of "core" package here is a judgment call made by SIG leadership. These are things like OpenSSL, OpenSSH, nss, glibc, rpm, etc. We don't want to put users at risk by fundamentally warping the way their Rocky system works and introducing issues. It may be possible to work around this by introducing an *additional* non-conflicting package version.
**Example:** if you're interested in packaging openssl-3.0.7 to Rocky 8, you wouldn't simply override the base openssl-1.1.1k which everything depends on. Instead, you might create a separate compatible package, "openssl-compat-307", which contains the newer library without conflicting with any files or library paths in the default openssl. **Example:** if you're interested in packaging openssl-3.0.7 to Rocky 8, you wouldn't simply override the base openssl-1.1.1k which everything depends on. Instead, you might create a separate compatible package, "openssl-compat-307", which contains the newer library without conflicting with any files or library paths in the default openssl.
- **It introduces a severe security risk**. This is again a judgment call made by the SIG as a whole. Generally this refers to extreme, remotely-exploitable security issues, usually 9.8 - 10 on the CVE/CVSS scale. If your package installs a listening daemon that is activated and allows remote commands without authentication, for example, that would be a clear reason not to have it available. - **It introduces a severe security risk**. This is again a judgment call made by the SIG as a whole. Generally this refers to extreme, remotely-exploitable security issues, usually 9.8 - 10 on the CVE/CVSS scale. If your package installs a listening daemon that is activated and allows remote commands without authentication, for example, that would be a clear reason not to have it available.
- **It already exists in EPEL, RPMFusion, or another common 3rd-party repo**. The intention of this SIG is to provide as much "new and cool" stuff to Rocky Linux users as possible. If people can already get software from one of the popular 3rd-party repos, that's probably the best place to go. Something we'd like to see as this SIG progresses is to use the initial work done here and add it to one of these more established repositories. - **It already exists in EPEL, RPMFusion, or another common 3rd-party repo**. The intention of this SIG is to provide as much "new and cool" stuff to Rocky Linux users as possible. If people can already get software from one of the popular 3rd-party repos, that's probably the best place to go. Something we'd like to see as this SIG progresses is to use the initial work done here and add it to one of these more established repositories.
- **Exception** to the "already exists" guideline: If the duplicate package is a dependency, and we need it in order to build the new package that we actually want to publish
- **It clearly belongs in another SIG**. The goal of this SIG is to be a "catchall" for new or enhanced Enterprise Linux packages. However, many times a package clearly doesn't belong in FastTrack, but in another SIG already set up around that package's area. Enhanced kernels should probably go in SIG/Kernel, embedded or single-board specific packages should go in SIG/AltArch, etc. - **It clearly belongs in another SIG**. The goal of this SIG is to be a "catchall" for new or enhanced Enterprise Linux packages. However, many times a package clearly doesn't belong in FastTrack, but in another SIG already set up around that package's area. Enhanced kernels should probably go in SIG/Kernel, embedded or single-board specific packages should go in SIG/AltArch, etc.
Outside of these listed areas, if someone puts in the effort to build and test a package against Rocky Linux, and it helps users in some way, it is welcome to be included in this SIG. Outside of these listed areas, if someone puts in the effort to build and test a package against Rocky Linux, and it helps users in some way, it ought to be a welcome inclusion in this SIG.
<br /> <br />
@ -43,11 +46,11 @@ TLDR:
- Packages stored in: https://git.rockylinux.org/sig/fasttrack/src/PKG - Packages stored in: https://git.rockylinux.org/sig/fasttrack/src/PKG
- Wiki/docs/OtherInfo stored in: https://git.resf.org/sig_fasttrack/* (should we just throw it all in git.rockylinux.org?) - Wiki/docs/OtherInfo stored in: https://git.resf.org/sig_fasttrack/*
- https://git.rockylinux.org/sig/fasttrack/{rpms,patch} also exist. Peridot imports src/PKG --> rpms/PKG - https://git.rockylinux.org/sig/fasttrack/{rpms,patch} also exist. Peridot imports src/PKG --> rpms/PKG
- Peridot will be doing package builds and publish, in accordance with other SIGs - Peridot will be doing package builds and publish, in accordance with other SIGs. One Peridot project per major Rocky version (FastTrack-8, FastTrack-9, etc.).
- Maintainers should have commit control over git.rockylinux.org/sig/fasttrack/src/PKG/ . And be able to take merge requests, add new versions, etc. - Maintainers should have commit control over git.rockylinux.org/sig/fasttrack/src/PKG/ . And be able to take merge requests, add new versions, etc.
@ -65,9 +68,14 @@ Pull requests should never violate the guidelines listed above (like introduce a
## Builds ## Builds
Builds done in Peridot, can test locally in Mock, against BaseOS+AppStream+CRB+Devel. Mock configs matching what is done in Peridot should be provided, so contributors can easily develop/test. Builds done in Peridot, can test locally in Mock, against BaseOS+AppStream+CRB+Devel, plus the SIG-FastTrack packages themselves of course. Mock configs matching what is done in Peridot should be provided, so contributors can easily develop/test on their own machines as well.
**Big question**: Do we want the SIG to be dependent on EPEL, and build against that as well? Potential huge benefit of allowing way more packages (EPEL has a lot of dependencies), but potential pitfall of stability. <br />
Would imply `sig-fasttrack-release` package depending on `epel-release` ## Repositories
3 repositories should be defined: **FastTrack-Updates** , **FastTrack-New** , and **FastTrack-common**.
Updates are newer versions of stock Rocky packages. New consists of new packages entirely.
It's an open question whether the -Updates repository should be enabled by default when a user installs the SIG-FastTrack-Release package.