Developer/Fedora: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (First pass.)
 
m (Partial lexicon)
Line 2: Line 2:


OLPC maintains a variant of the F-7 Fedora Linux distribution. Over the course of their careers developing for the XO, most developers eventually need to package software for the XO, either because they wish to fix a bug in software contained in an existing package or because they wish to contribute new software (other than activities) to the system. This document is intended to explain how to package bug fixes for OLPC system software that is maintained in Fedora. Other documents, such as [http://fedoraproject.org/wiki/PackageMaintainers/Join] discuss the less common case of adding entirely new pieces of software to Fedora and of adding new activities, which are not currently maintained in Fedora.
OLPC maintains a variant of the F-7 Fedora Linux distribution. Over the course of their careers developing for the XO, most developers eventually need to package software for the XO, either because they wish to fix a bug in software contained in an existing package or because they wish to contribute new software (other than activities) to the system. This document is intended to explain how to package bug fixes for OLPC system software that is maintained in Fedora. Other documents, such as [http://fedoraproject.org/wiki/PackageMaintainers/Join] discuss the less common case of adding entirely new pieces of software to Fedora and of adding new activities, which are not currently maintained in Fedora.

== Terminology ==

;upstream authors
: are people who release source code for consumption by '''package maintainers''' and who accept or reject patches from interested individuals

;package maintainers
: are people who accept source code releases from '''upstream authors''' and who combine that source code with '''packaging instructions''' in order to produce '''packaged software'''
: package maintainers are also responsible for contributing patches to '''upstream authors''' that fix bugs or that make the upstream software inter-operate more smoothly with other software
: ''Frequently in OLPC, package maintainers and upstream authors are the same person.''

;source releases
: are typically tarballs of source code that have been permanently published at a fixed URL, along with validation data such as MD5sums or the author's public key and a digital signature.
: (it's important for many reasons that source code be _permanently_ accessible for all packages. _Please_ make sure that yours is.)

;packaging instructions
: consist of a '<pkg-name>.spec' file and zero or more patches to a source release.



== Instructions ==
== Instructions ==

Revision as of 00:40, 31 January 2008

Introduction

OLPC maintains a variant of the F-7 Fedora Linux distribution. Over the course of their careers developing for the XO, most developers eventually need to package software for the XO, either because they wish to fix a bug in software contained in an existing package or because they wish to contribute new software (other than activities) to the system. This document is intended to explain how to package bug fixes for OLPC system software that is maintained in Fedora. Other documents, such as [1] discuss the less common case of adding entirely new pieces of software to Fedora and of adding new activities, which are not currently maintained in Fedora.

Terminology

upstream authors
are people who release source code for consumption by package maintainers and who accept or reject patches from interested individuals
package maintainers
are people who accept source code releases from upstream authors and who combine that source code with packaging instructions in order to produce packaged software
package maintainers are also responsible for contributing patches to upstream authors that fix bugs or that make the upstream software inter-operate more smoothly with other software
Frequently in OLPC, package maintainers and upstream authors are the same person.
source releases
are typically tarballs of source code that have been permanently published at a fixed URL, along with validation data such as MD5sums or the author's public key and a digital signature.
(it's important for many reasons that source code be _permanently_ accessible for all packages. _Please_ make sure that yours is.)
packaging instructions
consist of a '<pkg-name>.spec' file and zero or more patches to a source release.


Instructions

There are two broad kinds of work that must be done to be able to take responsibility for maintaining an OLPC fork of a Fedora package - requesting authority to maintain a Fedora package and learning how to maintain a Fedora package. Fortunately, these tasks can be performed in parallel.

Requesting Authority to Help Maintain an Existing Package or Branch of a Package

  1. Announce interest in helping with fork X
  2. Request a RedHat Bugzilla account
  3. Request a Fedora account
  4. Sign the Fedora Contributors License Agreement (CLA)
  5. Request membership in the cvsextras group.
  6. Ask a Fedora Package Maintainer (such as most OLPC developers) to sponsor you.
  7. Request authority to update the OLPC branch of the package you want to fix.

Learning How to Maintain a Package

  1. Get an account on teach.laptop.org, install Fedora yourself, or install appropriate packages if your distribution supports them;
  2. Anonymously check out your package from Fedora CVS
  3. Use mock or rpmbuild to learn how to build your package
  4. [Politely] Seek help from OLPC and Fedora developers as you discover confusions.