New Package Process in a Merged World
The following attempts to document what needs to be done to accomplish various tasks in a merged world. It is not intended to be all inclusive, however it should provide enough information for packagers familiar with the process for what was formerly called Fedora Extras.
The build system for Fedora development (and F7) is now called Koji. This provides some new features for both developers and the ReleaseEngineering team. To install koji, follow the instructions found on the Core/Extras Merge FAQ . Below are some definitions you should be familiar with in relation to the new buildsystem and package process.
- Build: A build is exactly the same as it was in plague. It represents an SRPM created from sources from CVS with a particular tag that has been built into RPMs on the buildsystem. A build will always relate to a particular name, version, and release (NVR) of a package.
- Tasks: A task is a currently on-going job that is running on the buildsystem. This is typically a build, however it can also show up as a tag request or a small subset of other things that most package maintainers will not care about.
- Tags: A tag is an entirely new concept added to koji. Tags are used to designate sets of packages toward particular purposes. These are not to be confused with CVS tags. These buildsystem tags are used solely on built packages. The following tags are currently in use for Fedora development:
1. dist-fc7: This is the default tag that gets applied to a package when it is successfully built with koji 1. f7-final: This tag represents the collection of packages that will be included in the Fedora 7 release repository. It also currently represents what is known as "rawhide" or the Fedora development repository, as usable by yum. Note that packages are not automatically tagged with this. This means that if you build a package with koji, and you would like to ensure your package build gets into the final Fedora 7 release repository, you have to follow the steps below.
Now that the entities formerly known as Fedora Core and Fedora Extras have been merged, the ongoing development freeze applies across the entire Fedora Package Collection. This differs quite a bit from the former Fedora Extras method of "build and release" mentality of package maintenance. Below is a representation of a package update while the repositories are under a freeze.
1. Update the package in CVS. This is done the same way as it was before the Core/Extras merge 1. Build it locally in mock and test the result. Again, this is done as it was before 1. Commit the changes to CVS, and run 'make tag' as before 1. Perform a build in koji with either 'make build' or 'make koji'. This will show you live status information of your build from the buildsys as it builds your package Up to this point, everything has been identical to the old method of package maintenance. Below is where things start to differ.
1. Once your package successfully builds, koji will automatically tag it with the dist-fc7 tag. This will make it available for other packages on the buildsys to use as a BuildRequires. The dist-fc7 tag is the logical equivalent of the 'needsign' repository that was used with plague. If you do not wish it to be present in the final Fedora 7 repositories or what is known as "rawhide" or the Fedora development repository, then you are essentially done. However, if you wish for your package to be included in the "rawhide" and final Fedora 7 repositories, proceed to the next step. 1. While under development freeze, an extra step is required to get a package tagged with the f7-final tag. Essentially, you will need to follow the Development Freeze policy . This policy has been put in place to aid in stabilizing the trees for final Fedora 7 release. Typical response time for rel-eng requests are within a day, however be aware that it is a manual process and may be slower at times.
Given the new steps required to get a build into the "rawhide" and final F7 repositories during the freeze, package maintainers need to be aware of potential upgrade path issues when updating a package across Fedora Extras 6 and Fedora 7. If an update is performed in both branches, but the f7 build is not tagged with "f7-final", you may have introduced a broken upgrade path if the FE6 build has a higher EVR than the build that is currently included in the "f7-final" tag. As a best practice, maintainers are encouraged to build for f7 and submit a rel-eng request before building the FE-6 package.
Q: What happens to the packages tagged with dist-fc7 but not f7-final
A: Packages tagged with dist-fc7 but not tagged with f7-final will not be included in the "rawhide" or Fedora 7 repositories. They remain available in koji however
Q: Will I need to rebuilt my packages when Fedora 8 development begins?
A: No. A new tag called "dist-fc8" will be created when the buildsystem and CVS repositories are ready for Fedora 8 development to begin. The "dist-fc8" tag will inherit all of the packages from "dist-fc7" to start with, so you will not need to rebuild your packages simply to get them included.
Q: Will the rel-eng request process apply to updates for Fedora 7 after it has been released?
A: No. There will be a different process for releasing updates to Fedora 7 after it has been released. A new tool called Bodhi is being developed to aid packagers in creating update announcements.
Q: Can I tag my own packages with f7-final?
A: No you cannot. You need to email your request to email@example.com . The release team is pretty reasonable, and they don't bite.
Q: Why do we need this whole Freeze process? It seems like added overhead when compared to how Extras did things
A: There is indeed added overhead when compared to the former Extras process. However, the merge is a two way street. The added overhead aids the Release team in producing quality, stabilized trees during the final steps of preparing a release. Please remember that for the majority of the time, development of a release is not impeded by this process. It is only active during freeze stages of a release cycle .