{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"SIG/FastTrack Wiki","text":""},{"location":"#a-package-bazaar-not-a-package-cathedral","title":"A Package Bazaar, not a Package Cathedral","text":"
FastTrack, as an ode to a past CentOS repository of a similar name, is a SIG that attempts to provide:
The goal is to have a place in the Rocky project where experimental new packages and updates to existing ones can be published. Philosophically, this SIG should be wide open to contributions, with much less rigor or vetting than repositories such as EPEL. Newer versions of existing Rocky Linux packages, as well as brand new packages are both welcome. We don't need reasons to add a package, we need reasons to not add it.
Having said that, we can't have absolute anarchy. There must be some kind of a guideline to what can and cannot be accepted.
"},{"location":"#reasons-for-fasttrack-package-rejection","title":"Reasons for FastTrack Package Rejection:","text":"dnf repoclosure
must succeed on publication. If some packages are not installable under default Rocky Linux, we cannot include the package until that's fixedopenssl
or glibc
with questionable behavior or API updates. \"Core\" is in the eye of the beholder, but generally we want FastTrack users to continue using the solid Rocky Linux base.Outside of these guidelines, package contributions should always be welcome!
"},{"location":"#links","title":"Links","text":"mkdocs.yml # The configuration file.\ndocs/\n index.md # The documentation homepage.\n ... # Other markdown pages, images and other files.\n
"},{"location":"package_list/","title":"FastTrack Package List","text":""},{"location":"package_list/#fasttrack-updates","title":"FastTrack-Updates","text":"Package Major Version Reason Extra Notes Date Added"},{"location":"package_list/#fasttrack-new","title":"FastTrack-New","text":"Package Major Version Reason Extra Notes Date Added"},{"location":"repositories/","title":"Repositories","text":"There are 2 main FastTrack repositories: FastTrack-Updates and FastTrack-New .
The -Updates repository contains newer versions of packages found in Rocky Linux, while the -New repository is exclusively new packages.
"},{"location":"repositories/#updates-repo-includes-and-excludes","title":"Updates Repo: Includes and Excludes","text":"The FastTrack-Updates repository in particular could be an issue for some users - what if you are only interested in updating certain packages on your system, but leaving others alone? This is not a problem for FastTrack-New , as you can simply opt to not install packages you don't want.
To assist users, the FastTrack.repo file will have a couple comments explaining how to includepkgs
and excludepkgs
in DNF. Specifying includepkgs allows users to only receive updates for the listed packages, while excludepkgs allows them to ignore FastTrack updates of things they prefer to keep on the stock Rocky ones.
New packages can always be discussed for inclusion via issues at: https://git.resf.org/sig_fasttrack/meta/issues
The best/fastest way to get a package included in the SIG is to have the build pre-complete in tested. That is, have a working git repository or SRPM somewhere that you've confirmed builds properly against Rocky Linux. We can then bring the package into dist-git under https://git.rockylinux.org/sig/fasttrack/src/PACKAGE and build + publish in the Rocky build system.
"},{"location":"repositories/#builds","title":"Builds","text":"Package builds must build with Rocky Linux dependencies only. (BaseOS/AppStream/PowerTools/Devel/etc.)
Using 3rd party repos such as EPEL as dependencies is not allowed. 3rd party repositories are subject to change, and we do not want to depend on external packages in order to use SIG-FastTrack. If a package is dependent on other packages found in EPEL or other repos, these dependencies can be re-built and made available in the FastTrack repositories as well.
A standard Mock config will be made available in the SIG's Git space for each major version of Rocky Linux. These Mock configs will reflect the SIG's Peridot build settings, so proper apples-to-apples testing of builds can be done locally by contributors.
"}]}