Differences between revisions 3 and 4
Revision 3 as of 2006-06-02 10:50:27
Size: 2610
Editor: ?panthera
Comment:
Revision 4 as of 2006-06-02 10:57:23
Size: 2633
Editor: ?panthera
Comment:
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
 * If you are not a Debian Developer, please upload your backport somewhere, post a link to it on backports-user@lists.backports.org and ask for review and upload. Please note, that you are responsible for this backport from the time on when it was accepted on backports.org. This means, you have to keep track of the changes in unstable, update your backport when a new version enters testing and provide security updates when needed. If you are not willing or capable of doing this, you better ask someone else (e.g. on the mentioned mailinglist) to create and maintain the backport.  * If you are not a Debian Developer, please upload your backport somewhere (binaries and sources), post a link to it on backports-user@lists.backports.org and ask for review and upload. Please note, that you are responsible for this backport from the time on when it was accepted on backports.org. This means, you have to keep track of the changes in unstable, update your backport when a new version enters testing and provide security updates when needed. If you are not willing or capable of doing this, you better ask someone else (e.g. on the mentioned mailinglist) to create and maintain the backport.

From [http://www.backports.org www.backports.org]:

You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in.

Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. It is recommended to pick out single backports which fits your needs, and not to use all backports available.

Backporting - Best practise

Here is a (incomplete) list of rules you should follow to get a package into backports.org.

Basic rules

1. Backport packages only from testing, not unstable (except when updating already existing backports, backports from unstable are accepted for security fixes).

2. Use 'sarge-backports' as distribution, not stable or unstable.

3. Reduce the revision by one and append bpo${build_int}, e.g. 1.2.3-4 becomes 1.2.3-3bpo1.

4. Backport no Build-Depends if not absolutely needed.

5. Always build against plain sarge (and include other backports only if absolutely needed).

Uploading

  • If you are a Debian Developer, ask Norbert Tretowski to add your key to the keyring of backports.org in order to upload your package directly.
  • If you are not a Debian Developer, please upload your backport somewhere (binaries and sources), post a link to it on backports-user@lists.backports.org and ask for review and upload. Please note, that you are responsible for this backport from the time on when it was accepted on backports.org. This means, you have to keep track of the changes in unstable, update your backport when a new version enters testing and provide security updates when needed. If you are not willing or capable of doing this, you better ask someone else (e.g. on the mentioned mailinglist) to create and maintain the backport.

  • After (and sometimes even before) the backport was accepted, it may be a good idea to contact the maintainer of the package in Debian to tell him, that you backported his package.
  • If there is already a backport of your package of choice, but it's outdated and you want to update it, inform the person who backported the last accepted version about your intensions. You can get the information from http://www.backports.org/~formorer/

Miscellaneous

  • Do not convert a package to a lower debhelper version for creating the backport, debhelper 5 is already on backports.org, just use it.