|
|
| (148 intermediate revisions by 42 users not shown) |
| Line 1: |
Line 1: |
| {{Draft| | | {{admon/warning |This page has been moved out of the wiki. The current version of this document is located at https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/ Please update your bookmarks.}} |
| NFR only for developer Users. To complete for Tester, Mirror, & Other}}
| |
| = Fedora NFR (No Frozen Rawhide) HOWTO =
| |
| 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 <code>rawhide, development</code> and <code>pending</code>. | |
| | |
| * For more information on becoming a package maintainer, refer to [[PackageMaintainers/Join]]
| |
| * For more guidance on package updates, refer to [[PackageMaintainers/Package update guidelines]].
| |
| | |
| == Overview ==
| |
| Here you can find some preliminary information about the new process of Package Management. If you want to know the difference between <code>rawhide, development</code> and <code>pending</code> , 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 [[FIXME]]
| |
| | |
| 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.
| |
| * [[No_Frozen_Rawhide_coming_soon|No_Frozen Rawhide coming soon! New paths on mirrors!]]
| |
| <!-- #* Most of these questions are answered by our overview in the last section -->
| |
| | |
| == For Developer ==
| |
| {{admon/note|
| |
| If you want to build a new package, but you aren't sure if it should go to Rawhide or {{FedoraVersion|long|next}}, 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 above.}}
| |
| | |
| * If you want build package for Rawhide available for testing:<BR>No action required. Happens [[Releases/Rawhide#Nightly_live_builds | nightly automatically]].
| |
| | |
| * If you want build critical & non-critical path package for {{FedoraVersion|long|next}}:<BR>Check out and build from the F-13/ branch as indicated below.
| |
| | |
| * Check out and build from the {{FedoraVersion|long|next}}/ branch
| |
| # Request a testing update in [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] for {{FedoraVersion|long|next}}. Bodhi admins "push" it.
| |
| # Peers and members from QA or Releng test the update and provide karma feedback via bodhi
| |
| | |
| * If you want build your package for {{FedoraVersion|long|next}} available for testing:<BR>
| |
| # You can request a testing update in [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] for {{FedoraVersion|long|next}}. Bodhi admins "push" it.
| |
| # You can peer test the update and provide karma feedback via bodhi
| |
| | |
| {{admon/tip|
| |
| To check and see if the build will be in the {{FedoraVersion|long|next}}, as they will be tagged with ''"dist-f1?"'', you can run ''koji latest-pkg dist-f1?'' to see what the latest build of your package is for {{FedoraVersion|long|next}}.}}
| |
| | |
| * You built a package to handle an urgent issue (e.g. security problem, non-functioning system, etc.) and want to push it to the {{FedoraVersion|long|next}} branch.<BR>You should build in the {{FedoraVersion|long|next}} branch and create a bodhi update and do one of the following:
| |
| # in all cases, you need to be very very very sure the update will not cause additional problems
| |
| # if the package is not in the critical path, nor addressing a security problem, then you request a push to stable.
| |
| # if the package addresses a security issue then you mark it as security and waits for the Security team to sign off on the update (not sure how this happens right now) before requesting the package be pushed to stable.
| |
| # if the package is in the critical path, then you also wait for a QA/releng/peer net positive karma vote in [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] before requesting the package be pushed to stable.
| |
| | |
| * If you have a package in the "pending" updates-testing repo for a week that hasn't received karma feedback
| |
| # If the package is in the critical path...<BR> You need to query QA/releng and peers to recieve karma for your update before you can proceed
| |
| # If the package is not in the critical path...<BR> You can choose to push to stable, or request and wait for further testing
| |
| | |
| * If you want to build a package for the Pending {{FedoraVersion|long|next}} but it requires package that is not yet pushed "stable" for {{FedoraVersion|long|next}}.
| |
| # You would need to file a buildroot override tag request as outlined in the policy page [[Alpha_Freeze_Policy | Alpha_Freeze_Policy]]
| |
| # Once tagged, you can proceed to build your package and issue the [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] request
| |
| | |
| * Make test update "stable" and tagged for {{FedoraVersion|long|next}}<BR>Provided the package has net positive Karma from QA or releng and at least one more net positive karma point, you should request a push to "stable" within [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] (this could be automatically done if karma autopush is checked). Bodhi admins "push" it.
| |
| | |
| == For Tester ==
| |
| * If you are o want to be a tester and want to install rwahide on your system to test the latest and greatest packages at all times than:
| |
| # Read the http://fedoraproject.org/wiki/Releases/Rawhide wiki page and follow the instructions to get rawhide installed.
| |
| # Leave the ''rawhide'' yum repo enabled and keep ''fedora'', ''updates'', and ''updates-testing'' repos disabled.
| |
| # Consume the rawhide firehose and report issues as you find them.
| |
| | |
| * If you want to install and run the 'pending' Fedora release (aka {{FedoraVersion|long|next}}) as your desktop and to participate in test days
| |
| # Install from Alpha, Beta, the Last Known Good ''Pending'' snapshot or from a ''Pending'' nightly live image
| |
| # yum update to the latest pending content
| |
| | |
| * If you want to update your Fedora 12 system to the ''Pending'' Fedora 13 and start testing Fedora 13<BR> Update your existing Fedora 12 system by reading instructions at [[FIXME]]
| |
| | |
| * If you want to pitch in and provide test feedback for new packages ... where do you go? ('Rawhide', 'pending' updates-testing, 'stable' updates-testing)<BR> You would check the [[QA/Join]] page that describes the different testable repos and skill level and investment involved. You would make a decision and follow documentation on how to test.
| |
| | |
| * If you want to impress your friends by becoming a member of the QA team so that you can represent QA in providing positive feedback on critical path package updates on the 'stable' and 'pending' fedora releases
| |
| # You read the [[QA/Join]] page and demonstrate an ability and desire to do the testing and provide useful feedback and applie for the official QA group
| |
| # You read the [[QA:Package Acceptance Test Plan]] and use it as a guideline to test things.
| |
| # Tangent - We have a completely unused 'qa' FAS group ... do we wipe the list and start over? (It's possible to do that, but before you do, you can email 'qa-members@fp.o' to take care of advance notice... i.e. give people a heads-up, make sure everyone understands why, and what they should do next, whether it's join another group, speak up to keep membership, or what have you)
| |
| | |
| * If you are a member of the QA FAS group. You provided positive feedback on a 'pending' or 'stable' package update. The package update is released and includes a major regression. What now?
| |
| # Would review in weekly QA meeting. It's ok, mistakes happen
| |
| # Accident/omission
| |
| # Misuse
| |
| | |
| == For Mirror Admin ==
| |
| * If you are a mirror admin and want to prepare for additional repos coming to his mirror
| |
| ** Read mirror-list(-d) and watche for announcements regarding new paths being added to the master mirror
| |
| ** Check his sync exclusion settings to ensure you either get, or don't get the new path depending on your desires.
| |
| | |
| == Build a package for Rawhide ==
| |
| To build a package for Rawhide, check it out from the CVS devel/branch.
| |
| | |
| Install fedora-packager if not already installed.
| |
| | |
| Check out a local working copy of the CVS module you plan to edit, e.g. (for a description of the directory layout, see the [[PackageMaintainers/Anatomy| Anatomy]] page:
| |
| <pre>fedora-cvs <package_name>
| |
| </pre>
| |
| | |
| * 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
| |
| | |
| <pre>fedora-cert -n</pre>
| |
| | |
| To upload a new source tarball and replace an older one, run
| |
| | |
| <pre>make new-sources FILES="/path/to/yournewtarball.tar.gz"
| |
| </pre>
| |
| | |
| 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:
| |
| <pre>make new-sources FILES="yournewtarball.tar.gz yourdata.tar.gz"
| |
| </pre>
| |
| | |
| 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:
| |
| <pre>make upload FILES="somefile.tar.gz"
| |
| </pre>
| |
| Contrary to <code>make new-sources</code>, this does not purge old files from the <code>.cvsignore</code> and <code>sources</code> files.
| |
| | |
| If you just have a small patch, initscript, or otherwise plain text file, you can commit those directly to CVS. This can be done with the <code>cvs add</code> command, e.g.:
| |
| <pre>cvs add packagename-fix-the-foobar.patch
| |
| </pre>
| |
| | |
| * Use the command <code>make i686</code> or <code>make x86_64</code> 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:
| |
| <pre>make srpm; koji build --scratch --arch-override x86_64 dist-f14 packagename-version-release.src.rpm
| |
| </pre>
| |
| | |
| * Check if everything that has changed is correct with
| |
| <pre>cvs diff -u
| |
| </pre>
| |
| | |
| * Commit the verified changes to the <code>devel/</code> branch.
| |
| <pre>cvs commit
| |
| </pre>
| |
| | |
| 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.
| |
| * Tag your package:
| |
| <pre>make tag
| |
| </pre>
| |
| | |
| * Instruct the builders to build your package:
| |
| <pre>make build
| |
| </pre>
| |
| | |
| * Check the koji build page at http://koji.fedoraproject.org/koji/ for the build process.
| |
| | |
| === Example ===
| |
| | |
| <pre>
| |
| fedora-cvs foo
| |
| cd foo/devel
| |
| wget -N http://dl.sf.net/foo/foo-0.0.2.tar.bz2
| |
| make new-sources FILES="foo-0.0.2.tar.bz2"
| |
| gedit foo.spec
| |
| # change the required things in the specfile
| |
| make i686
| |
| # check that the changes you made are correct
| |
| cvs diff -u
| |
| # commit
| |
| cvs commit -m "Update to 0.0.2"
| |
| # request build
| |
| make tag build
| |
| </pre>
| |
| | |
| The package builders publish your package in the <code>development</code> 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 [[#Packages_in_the_stable_branches |next chapter]].
| |
| | |
| An alternative may be used, [[PackageMaintainers/UsingCvsFaq#Import_of_complete_src.rpm_packages| the import of a complete src.rpm]].
| |
| | |
| More in-depth information on the build system is at
| |
| [[PackageMaintainers/UsingKoji| UsingKoji]].
| |
| | |
| === 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. | |
| {{admon/caution|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:
| |
| | |
| <pre>
| |
| koji untag-pkg dist-f13 foo-1.1.3-1.fc13
| |
| </pre>
| |
| | |
| Where <code>foo-1.1.3-1.fc13</code> is replaced with the name of your package build. See <code>koji help</code> or [[PackageMaintainers/UsingKoji | UsingKoji]] for more information.
| |
| | |
| = Working with packages in the stable branches =
| |
| Stable branches are branches within CVS 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 <code>F-11</code>, <code>F-12</code> or <code>F-13</code>, etc.. directory. In many cases, you can apply the same changes from the <code>devel/</code> branch to the other branches. Use the <code>diff</code> and <code>patch</code> utilities for this purpose.
| |
| # Use the command <code>make i686</code> or <code>make x86_64</code> 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.
| |
| # Commit the verified changes to the branch you are working on: <pre>cvs commit</pre>
| |
| # Tag your package: <pre>make tag</pre>
| |
| # Instruct the builders to build your package:<pre>make build</pre>
| |
| # Check the koji build page at http://koji.fedoraproject.org/koji/ for the build process.
| |
| | |
| * If you want to build a package for the Pending {{FedoraVersion|long|next}} but it requires package that is not yet pushed "stable" for Fedora 13.
| |
| # You would need to file a buildroot override tag request as outlined in the policy page Alpha_Freeze_Policy
| |
| # Once tagged, you can proceed to build her package and issue the [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] request
| |
| | |
| == Submit your update to Bodhi ==
| |
| | |
| # This can be accomplished in a few different ways. The easiest being: <pre>make update</pre> If your local username differs from that of your Fedora account, you will need to specify it with the following command: <pre>make update BODHI_USER=foo</pre> Or you add <code>BODHI_USER=foo</code> to the file <code>~/.cvspkgsrc</code>.
| |
| ## Alternatively, you can also submit your update using the [https://fedorahosted.org/bodhi/wiki/CLI bodhi-client]
| |
| ## or the [https://admin.fedoraproject.org/updates web interface] .
| |
| # 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 [[Security/TrackingBugs |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!
| |
| | |
| == Get Automatically Notified on New Upstream Releases ==
| |
| To automatically get notifications via bugzilla whenever upstream has a new release, refer to [[Upstream_Release_Monitoring | upstream release monitoring]] page.
| |
| | |
| == Reference ==
| |
| http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq
| |
| {{admon/note|
| |
| If you want to build a new package, but you aren't sure if it should go to Rawhide or {{FedoraVersion|long|next}}, 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 [[ReleaseEngineering | Releng]] / [[QA]] and peers as outlined below.}}
| |
| {|
| |
| || || No action required. Happens [[Releases/Rawhide#Nightly_live_builds | nightly automatically]] || Check out and build from the Fedora 13/ branch and request a testing update in [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] for {{FedoraVersion|long|next}}. || Peers test the update and provide karma feedback via [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] || Members from [[QA]] or Releng test the update and provide karma feedback via [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] || Query [[QA]] / Releng and peers to receive karma for your update || Either push to ''stable'', or request and wait for further testing || File a buildroot override tag request as outlined in the [[Alpha_Freeze_Policy | Policy page]], and proceed to build the package and issue the [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] request
| |
| | |
| | |
| | |
| |-
| |
| || If you want build package for Rawhide available for testing || X || || || || || ||
| |
| |-
| |
| || If you want build critical & non-critical path package for Fedora 13 || || X || || X || || ||
| |
| |-
| |
| || If you want build your package for Fedora 13 available for testing: || || X || X || || || ||
| |
| |-
| |
| || If you have a package in the "pending" updates-testing repo for a week that hasn't received karma feedback || || || || || X (if package is in the critical path) || X (if package is not in critical path) ||
| |
| |-
| |
| || If you want to build a package for the Pending {{FedoraVersion|long|next}} which requires a package not yet pushed ''stable'' for {{FedoraVersion|long|next}} || || || || || || || X
| |
| |}
| |
| | |
| {{admon/tip|
| |
| To check and see if the build will be in the {{FedoraVersion|long|next}}, as they will be tagged with ''"dist-f1?"'', you can run ''koji latest-pkg dist-f1?'' to see what the latest build of your package is for {{FedoraVersion|long|next}}.}}
| |
| | |
| | |
| {{admon/note| Making test update ''stable'' and tagged for {{FedoraVersion|long|next}} |
| |
| <BR>Provided the package has net positive Karma from QA or releng and at least one more net positive karma point, request a push to ''stable'' within [[Package_update_HOWTO#Submit_your_update_to_Bodhi | Bodhi]] (this could be automatically done if karma autopush is checked). Bodhi admins "push" it.
| |
| }}
| |
| | |
| | |
| | |
| {|
| |
| || || Read the [[Releases/Rawhide | Rawhide]] page and follow the instructions to get rawhide installed.|| Leave the ''rawhide'' yum repo enabled and keep ''fedora'', ''updates'', and ''updates-testing'' repos disabled. || Consume the rawhide firehose and report issues as you find them.|| Install from Alpha, Beta, the Last Known Good ''Pending'' snapshot or from a ''Pending'' nightly live image || <code>yum update</code> to the latest ''pending'' content || Update your Fedora 12 system by reading instructions at [[FIXME]] || Check the [[QA/Join]] page that describes the different testable repos, skill level and investment involved. || Read the [[QA:Package Acceptance Test Plan]] and use it as a guideline for testing
| |
| | |
| |-
| |
| || If you want to be a tester and want to install rawhide on your system to test the latest and greatest packages at all times || X || X || X || || || || ||
| |
| |-
| |
| || If you want to install and run the ''pending'' Fedora release (aka {{FedoraVersion|long|next}}) as your desktop and to participate in test days || || || || X || X || || ||
| |
| |-
| |
| || If you want to update your Fedora 12 system to the ''Pending'' Fedora 13 and start testing it || || || || || ||X || ||
| |
| |-
| |
| || If you want to pitch in and provide test feedback for new packages ('Rawhide', 'pending', 'stable' updates-testing, ) || || || || || || || X ||
| |
| |-
| |
| || If you want to impress your friends by becoming a member of the QA team so as to represent it in providing positive feedback on critical path package updates on the 'stable' and 'pending' fedora releases || || || || || || || X || X
| |
| |-
| |
| |}
| |
| [[Category:Package Maintainers]][[Category:How to]]
| |
| | |
| {{admon/note| |
| |
| * 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
| |
| }} | |
