Package update HOWTO

From FedoraProject

This page is a draft only It is still under construction and content may change. Do not rely on the information on this page.
This page is under re-construction. It covers NFR only for developer Users. To complete for Tester, Mirror, & Other

Make sure you have updated to fedora-packager version 0.5.1 atleast before running any of the commands. Also run git config --global --add push.default tracking which instructs git to "push" to whatever branch you are tracking

This document shows how to update a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories.
This document is divided in three sections to give Developers, Testers, and Mirror Admins some guidelines on how to submit packages for rawhide, development and pending.

Overview

Here you can find some preliminary information about the new process of Package Management. If you want to know the difference between rawhide, development and pending , and which one is suitable for you, along with an overall understanding of the release naming and repos, visit our new and improved Fedora Development Process Overview page.

New contributors (mandatory reading), new Testers (highly suggested reading), new Consumers (useful reading), or anybody interested in how Fedora is developed would find this page useful.

In particular, these are the new paths on mirrors:

/pub/fedora/linux/development/rawhide/ will become the new path of Rawhide. It will continue to not have install images, and will be the place where builds from the "devel" branch in git go to. It'll be Fedora 22 intended content.

/pub/fedora/linux/development/13/ will become the new path of the branched Fedora 13 content. This is where builds from the F-13/ branch in git will go after they pass through Bodhi as "stable".

/pub/fedora/linux/updates/testing/13/ will be where potential Fedora 13 builds go after passing through bodhi as "testing". This is where you'll find the latest stuff proposed for freeze break and where testing and peer review of these freeze breaks will happen. When a maintainer feels enough testing has happened, or enough karma triggers the Bodhi auto request, the build will be marked "stable" and show up in the development/13 tree at the next nightly compose.

For Developers

If you want to build a new package, but you aren't sure if it should go to Rawhide or Fedora 22, then:

New packages should always be built at least for Rawhide

New packages can be built for Pending and existing Fedora Releases, however they should go through updates-testing first. If the new package is critical-path it will require net positive karma from Releng / QA and peers as outlined below.

To install and run Fedora 22 as your desktop and participate in test days

X

X

To update a Fedora 12 system to the Pending Fedora 13 for testing

X

To provide test feedback for new packages

X

To represent the QA team in providing feedback on critical path package updates

X

X

If you are a member of the QA FAS group, and provided positive feedback on a 'pending' or 'stable' package update. The package update is released and includes a major regression. What now?

Review in weekly QA meeting. It's ok, mistakes happen.

Accident/omission.

Misuse

For Mirror Admins

If you are a mirror admin and want to prepare for additional repos coming to your mirror :

Read mirror-list(-d) and watch for announcements regarding new paths being added to the Master Mirror.

Check your sync exclusion settings to ensure you either get, or don't get the new path (depending on your needs).

Build a package for Rawhide

To build a package for Rawhide, check it out from the git devel/branch.

Install fedora-packager if not already installed.

Check out a local working copy of the git module you plan to edit, e.g. (for a description of the directory layout, see the Anatomy page:

fedpkg clone <package_name>

If you update to a new upstream version, you have to upload the tarball to an external lookaside cache. Operations on the lookaside cache require a client-side certificate, to get one, run

fedora-cert -n

To upload a new source tarball and replace an older one, run

fedpkg new-sources /path/to/yournewtarball.tar.gz

You can omit the path if the source is the current directory.

In the branch directory (i.e. devel in this case) or for multiple files:

fedpkg new-sources yournewtarball.tar.gz yourdata.tar.gz

This also updates your local copy of the .cvsignore and sources files. You will need to do this for each branch that you will be building the new version for. The new tarball will be uploaded only once and the rest will be md5sum checked and not uploaded, only the .cvsignore and sources files will be updated.

If you just want to add another tarball (e.g. a big gzipped patch or a documentation tarball), use:

fedpkg upload somefile.tar.gz

Contrary to fedpkg new-sources, this does not purge old files from the .cvsignore and sources files.

If you just have a small patch, initscript, or otherwise plain text file, you can commit those directly to git. This can be done with the git add command, e.g.:

git add packagename-fix-the-foobar.patch

Use the command fedpkg i686 or fedpkg x86_64 to test a package build on your local system. Then install and test the package. If something doesn't work, fix it and repeat this step. You can also use the koji build system to do a scratch build perhaps for some arch you don't have locally. For example, to build just for x86_64:

As a test whether the full commit was fine, you can check out a fresh working copy into a different directory. It should succeed in fetching the binaries from lookaside cache and also pass simple build tests such as make i686 or make srpm at least.

The package builders publish your package in the development tree, also called "Rawhide." If the package is a stable update, you may also provide it to users of the currently-maintained stable, or branched Fedora release. To make it available to F-11 or F-12 users, or testers of the branched F-13 for example, use the procedure outlined in the next chapter.

Removing a package build from the devel branch

From time to time you may want to remove a package build you pushed to the devel branch (rawhide). This could happen in a situation where a bug
or issue is found in your package that will be resolved upstream in the next release. You may want to wait for this release instead
of back-porting a fix yourself, so pulling the broken package from rawhide makes sense.

Use this carefully!This should only be done on the same day of the build. If your build has already been published in rawhide you must not untag it!

You can remove the package from rawhide by using koji as follows:

koji untag-pkg dist-f13 foo-1.1.3-1.fc13

Where foo-1.1.3-1.fc13 is replaced with the name of your package build. See koji help or UsingKoji for more information.

Requesting special dist tags

When updating a package affects a large number of dependencies (e.g. all perl, python or ghc packages) it may be better to initially do the builds in another repo, so that there is less disruption in rawhide.

If you think you have an update that falls under this case you can request a special dist tag by filing a release engineering ticket. Someone from release engineering will likely want to discuss your needs to make sure this is really an appropriate case (it's OK ask if you aren't sure) and that you get what you need.

Working with packages in the stable branches

Stable branches are branches within git for either released Fedoras, or a branched Fedora that is still in bugfix/polish mode but has not yet been released.

Make any required changes in the F-11, F-12 or F-13, etc.. directory. In many cases, you can apply the same changes from the devel/ branch to the other branches. Use the diff and patch utilities for this purpose.

Use the command fedpkg i686 or fedpkg x86_64 to test a package build on your local system. Then install and test the package. If something doesn't work, fix it and repeat this step.

Once submitted, bodhi will automatically request that your update be pushed to updates-testing. If you feel that community testing is unnecessary for your update, you can choose to push it straight to the stable fedora-updates repository instead. Pushing directly to stable skips peer review and is strongly discouraged!! Note that security updates follow a slightly different process .

A Release Engineer then signs and pushes out your updates. The signing step is currently a manual process, so your updates will not be instantly released once submitted to bodhi.

Once pushed to testing, people are able to +1/-1 the updates "karma", based on whether or not it seems to be functional for them. If your update reaches a karma of 3, it will automatically be pushed to stable. Likewise, if it reaches -3, it will be automatically unpushed. If your update does not receive enough feedback to automatically push it to stable, you will have to submit it as a final update yourself. This can easily be done with the command-line tool, or with the web interface.

You will then be notified when your update has been pushed to stable. Bodhi will close all associated bugs and send an announcement to fedora-package-announce. At this point, your update has been officially released!