Differences between revisions 12 and 13
Revision 12 as of 2006-06-10 23:07:03
Size: 4914
Editor: ?panthera
Comment:
Revision 13 as of 2006-06-14 08:09:44
Size: 5121
Editor: ?panthera
Comment:
Deletions are marked like this. Additions are marked like this.
Line 52: Line 52:
 * 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.  * 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 you are not already subscibed to backports-users@lists.backports.org, please do so. There might be questions/problems from users regarding your backport(s), which you can answer best and hopefully solve.

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). If you backport from unstable anyway, you may like [#check-backports-script this script] to tell you when you can go ahead.

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).

6. If there is no previous Debian revision of your package in the backports archive (same upstream version), don't forget to include the source tarball by passing -sa to dpkg-buildpackage or dpkg-genchanges.

Uploading

If you're using dupload on testing/sid (there is a patched version of dput on backports.org already), you can add

package config;
$cfg{'bpo'} = {
    fqdn => "www.backports.org",
    incoming => "/",
};
1

to your ~/.dupload.conf file. For dput, use the following in ~/.dput.cf:

[bpo]
fqdn = www.backports.org
incoming = /
method = ftp
login = anonymous
  • 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 you are not already subscibed to backports-users@lists.backports.org, please do so. There might be questions/problems from users regarding your backport(s), which you can answer best and hopefully solve.

  • 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.

Checking whether a package is ready for backports.org

?Anchor(check-backports-script)

You can use the following script to check which packages are ready for upload, in case you built unstable packages and are waiting for the respective versions to trickle to testing. This script assumes you have all your backports.org .changes files names properly (*bpo*.changes), and that they're all underneath the directory you pass as argument:

#
# check-backports -- checks which packages can be uploaded to backports.org
#
# the script takes one parameter: the base directory holding .changes files.
# it will output the names and versions of packages ready for upload.
#
# Copyright © 2006 martin f. krafft <madduck@debian.org>
# Released under the terms of the Artistic Licence.
#
# Version: 2006.06.08.0042
#

get_testing_version()
{
  wget -qO- http://packages.qa.debian.org/${1} \
    | sed -ne '0,/labelcell.*Testing/d;N;s/[^>]*>\([^<]*\)<.*/\1/p;q'
}

get_changes_files()
{
  find $1 -name \*bpo\*.changes | sed -e 's,.*/,,'
}

IFSOLD=$IFS
IFS=_
get_changes_files $1 | while read pkg ver archchanges; do
  tver=$(get_testing_version $pkg)
  if dpkg --compare-versions "$tver" gt "$ver"; then
    echo "$pkg $ver can be uploaded to backports.org."
  fi
done

exit 0