|
|
| (11 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| == Description ==
| |
| <!-- Put a description of the task here.
| |
| -->
| |
| Each new release we create a build target for the next release. This SOP will describe the steps necessary to prepare the new build target.
| |
|
| |
|
| == Action ==
| | {{admon/important|This page has moved [https://docs.pagure.org/releng/sop_adding_side_build_targets.html here]| All Fedora Release Engineering Documentation has moved [https://docs.pagure.org/releng/ here] with source hosted along side the code in the [https://pagure.io/releng releng pagure repository]}} |
| <!-- Describe the action and provide examples
| |
| -->
| |
| Adding a build target is a complicated task. It involves updating koji, CVS, fedora-release package, and a few wiki pages.
| |
|
| |
|
| === Koji ===
| |
| In koji a couple collection tags need to be made, and a target created to tie them together. We create a base collection tag named after the release, and a build tag to hold a few things we use in the buildroots that are not part of the distribution (glibc32/glibc64). Inheritance to the previous release is used for ownership and package data, as well as buildroot content data.
| |
|
| |
| The <code>add-tag</code>, <code>add-tag-inheritance</code>, <code>edit-tag</code>, and <code>add-target</code> commands are used.
| |
| <pre>
| |
| $ koji add-tag --help
| |
| Usage: koji add-tag [options] name
| |
| (Specify the --help global option for a list of other help options)
| |
|
| |
| Options:
| |
| -h, --help show this help message and exit
| |
| --parent=PARENT Specify parent
| |
| --arches=ARCHES Specify arches
| |
|
| |
|
| |
| $ koji add-tag-inheritance --help
| |
| Usage: koji add-tag-inheritance [options] tag parent-tag
| |
| (Specify the --help global option for a list of other help options)
| |
|
| |
| Options:
| |
| -h, --help show this help message and exit
| |
| --priority=PRIORITY Specify priority
| |
| --maxdepth=MAXDEPTH Specify max depth
| |
| --intransitive Set intransitive
| |
| --noconfig Set to packages only
| |
| --pkg-filter=PKG_FILTER
| |
| Specify the package filter
| |
| --force=FORCE Force adding a parent to a tag that already has that
| |
| parent tag
| |
|
| |
| $ koji edit-tag --help
| |
| Usage: koji edit-tag [options] name
| |
| (Specify the --help global option for a list of other help options)
| |
|
| |
| Options:
| |
| -h, --help show this help message and exit
| |
| --arches=ARCHES Specify arches
| |
| --perm=PERM Specify permission requirement
| |
| --no-perm Remove permission requirement
| |
| --lock Lock the tag
| |
| --unlock Unlock the tag
| |
| --rename=RENAME Rename the tag
| |
|
| |
| $ koji add-target --help
| |
| Usage: koji add-target name build-tag <dest-tag>
| |
| (Specify the --help global option for a list of other help options)
| |
|
| |
| Options:
| |
| -h, --help show this help message and exit
| |
| </pre>
| |
|
| |
| For example if we wanted to create the Fedora 14 tags, we would do the following:
| |
| <pre>
| |
| koji add-tag --parent dist-f13-updates --arches=i386,x86_64 dist-f14
| |
| koji add-tag --parent dist-f14 --arches=i386,x86_64 dist-f14-updates
| |
| koji add-tag --parent dist-f14-updates --arches=i386,x86_64 dist-f14-updates-candidate
| |
| koji add-tag --parent dist-f14-updates dist-f14-updates-testing
| |
| koji add-tag --parent dist-f14-updates dist-f14-override
| |
| koji add-tag --parent dist-f14-override --arches=i386,x86_64 dist-f14-build
| |
| koji add-tag-inheritance --priority 1 dist-f14-build dist-f13-build
| |
| koji edit-tag --perm=admin dist-f14-override
| |
| koji edit-tag --lock dist-f14-updates
| |
| koji add-target dist-f14 dist-f14-build
| |
| </pre>
| |
|
| |
| === CVS ===
| |
| Multiple parts of the CVS system need to be made aware of new build targets (and thus new branches).
| |
|
| |
| ==== common/ ====
| |
| The branches file needs to be updated.
| |
|
| |
| branches simply needs a new line defining the next release:
| |
| <pre>
| |
| F-9:dist-f9:.fc9:fedora:9
| |
| </pre>
| |
| The first field is the branch name as it would be seen on the file system. The second field is the build target for that branch, the third is what dist would define to, and the last to define the family and release (which are used by other macros). Depending on when the new target is introduced, you may need to also update the definition of the devel/ branch so that it targets the correct build target.
| |
|
| |
| ==== CVSROOT/admin/ ====
| |
| Within CVSROOT/admin/ there are several files that deal with making CVS branches. They are mkbranchwrapper, pkgdb2branch.py, and tag-check.
| |
|
| |
| mkbranchwrapper simply needs the <code>VALID_BRANCHES</code> alias updated with the new branch:
| |
| <pre>
| |
| VALID_BRANCHES="OLPC-2 FC-3 FC-4 FC-6 F-7 F-8 EL-4 EL-5"
| |
| </pre>
| |
|
| |
| pkgdb2branch.py needs something similar. Update <code>BRANCHES</code> with the new branch information. The branch name maps to the branch that is its parent.
| |
| <pre>
| |
| BRANCHES = {'EL-4': 'FC-3', 'EL-5': 'FC-6',
| |
| 'OLPC-2': 'F-7',
| |
| 'devel': None,
| |
| 'RHL-8': None, 'RHL-9': None,
| |
| 'FC-1': None, 'FC-2': None, 'FC-3': None, 'FC-4': None, 'FC-5': None,
| |
| 'FC-6': None,
| |
| 'F-7': 'devel', 'F-8': 'devel', 'F-9': 'devel'}
| |
|
| |
| </pre>
| |
|
| |
| tag-check lists a set of tags that are valid and as such it needs to be updated with the tags that are created when a package is branched. These are branch starting tags and branch splitting tags. Each set needs to get updated with the new branch:
| |
| <pre>
| |
| RHL-8-start | RHL-9-start | \
| |
| OLPC-2-start | \
| |
| EL-4-start | EL-5-start | \
| |
| FC-1-start | FC-2-start | FC-3-start | FC-4-start | FC-5-start | \
| |
| FC-6-start | F-7-start | F-8-start )
| |
| </pre>
| |
| <pre>
| |
| RHL-8-split | RHL-9-split | \
| |
| OLPC-2-split | \
| |
| EL-4-split | EL-5-split | \
| |
| FC-1-split | FC-2-split | FC-3-split | FC-4-split | FC-5-split | \
| |
| FC-6-split | F-7-split | F-8-split )
| |
| </pre>
| |
|
| |
| === PackageDB ===
| |
| {{admon/note||For PackageDB, add the branches you want to be able to make in cvs when you want to be able to make them. ie, when cvs early branching for Fedora 9 from rawhide is desired, create the Fedora 9 collection in pkgdb.}}
| |
| The Package Database has two tables that need to be updated with the new release information as well. These are the commands that were run to update for Fedora 9:
| |
|
| |
| <pre>
| |
| $ ssh bastion
| |
| $ ssh db2
| |
| $ sudo -u postgres psql pkgdb
| |
| Password:
| |
| pkgdb=# insert into collection (name, version, koji_name, statuscode, owner) values \
| |
| ('Fedora', '9', 'dist-f9', 1, 100351);
| |
|
| |
| pkgdb=# insert into branch (collectionid, branchname, disttag) \
| |
| select id, 'F-9', '.fc9' from collection where name = 'Fedora' and version = '9';
| |
| </pre>
| |
|
| |
| * name and version define the release.
| |
| * koji_name is the tag used for this release in koji.
| |
| * statuscode for a new release will always be 1 (Active).
| |
| * 100351 is Jesse Keating's id. Change this if someone else is the release manager for this release.
| |
| * branchname is the name of branch directories in cvs.
| |
| * disttag is the value for disttag in rpm.
| |
|
| |
| === fedora-release ===
| |
| Currently the fedora-release package provides the '''%{?dist}''' definitions used during building of packages. When a new target is created, fedora-release must be built for the collection with new dist definitions.
| |
|
| |
| === Wiki ===
| |
| Various wiki pages need to be updated with the new target information. Below you'll find a (hopefully current) list of pages to change:
| |
| * [[Koji/CurrentKojiTags| Current Koji Tags]]
| |
| * [[PackageMaintainers/CVSAdminProcedure| CVS Admin Proceedure]]
| |
|
| |
| === Comps ===
| |
| * In the comps module in Fedora Hosted git (ssh://git.fedorarhosted.org/git/comps.git), create and add a new comps file based on the previous release. (Just copying it should be fine.) Add the new file to <code>po/POTFILES.in</code>.
| |
| * When rawhide is retargeted in koji to point to the new release, update the <code>Makefile</code> to target comps-rawhide.xml at the new version
| |
| * Don't forget to <code>git push</code> your changes after committing.
| |
|
| |
| == Verification ==
| |
| <!-- Provide a method to verify the action was successful
| |
| -->
| |
| Given the complexity of all the changes necessary to create a new build target, the best way to verify is to attempt a build. Given that fedora-release has to be built before anything else so that dist tags translate correctly it is a good test case. For example, this was used to test the new Fedora 9 target:
| |
|
| |
| * Use pkgdb to request an F-8 branch of fedora-release
| |
| * Use pkgdb2branch to actually make the branch
| |
| * Update fedora-release checkout (and common/ directory)
| |
| * Adjust .spec file in devel/ for new dist defines
| |
| * commit/build
| |
| * Track build in koji to ensure proper tagging is used
| |
|
| |
| What this won't test is translations of dist at tag time given that fedora-release doesn't use dist in it's Release. Verifying with a second package that uses dist is a good idea.
| |
|
| |
| == Consider Before Running ==
| |
|
| |
| * '''FIXME'''
| |
| * Too many to list right now.
| |
|
| |
|
| [[Category:Release Engineering SOPs]] | | [[Category:Release Engineering SOPs]] |
