...
 
Commits (4)
......@@ -2,15 +2,45 @@
##Packaging
###Introduction
The packages on debian-backports are made by volunteers. If you
like to help with backporting packages from the Debian archive, make sure you
follow these guidelines.
###Introduction
The packages on debian-backports are made by volunteers. If you like to help
with backporting packages from the Debian archive, make sure you follow these
guidelines or ask on the [mailing list] for clarification.
Backports are about additional features that are only offered in a new version,
not a replacement for getting fixes into stable - use stable-updates for that.
Backports tracks testing and only package versions included in testing are
allowed in it, subject to a few expedient exceptions.
##Eligibility
If you feel you would need to diverge from these rules, either discuss it on
the [mailing list] or bring it up with the [Backports Team] for an exception.
[mailing list]: https://lists.debian.org/debian-backports/
[Backports Team]: mailto:backports-team@debian.org
###Package
* Before uploading please think about how useful the package is for stable
users and if it is sensible to support the package for the full supported
lifetime of a release cycle (stable and oldstable).
* Don't backport minor version changes without user visible changes or bugfixes
* To guarantee an upgrade path from stable+backports to the next stable, the
package needs to be in testing. Security updates may be uploaded before the
testing migration completes. Other short-term exceptions can be granted for
e.g. library transitions, critical bugs on request from the [Backports Team].
* Please only upload package with a notable userbase. Backports is not a
maintainer's PPA; a user request for the package may be an indicator. Use
common sense and if in doubt, ask about the package on the [mailing list].
* Check the [backports NEW queue] before starting to avoid duplicated effort.
* If you want to update an existing outdated backport, please inform the person
who [backported] the last accepted version about your intentions.
[backports NEW queue]: https://ftp-master.debian.org/backports-new.html
[backported]: https://backports.debian.org/changes/stretch-backports.html
###Maintainer
Please note, that you are responsible for this backport from the time on when
......@@ -18,9 +48,7 @@ it was accepted on debian-backports. 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 [mailing list]) to create
and maintain the backport.
[mailing list]: https://lists.debian.org/debian-backports/
and maintain the backport.
An Uploader for the unstable package is the ideal person to maintain a backport
since they're already following the testing migration, so please contact them
......@@ -46,76 +74,44 @@ cycle, but they know about complicated dependencies you should discuss.
[backports queue]: https://rt.debian.org/Ticket/Create.html?Queue=20
[RT]: https://wiki.debian.org/rt.debian.org
[backports NEW queue]: https://ftp-master.debian.org/backports-new.html
[granted upload permission]: https://wiki.debian.org/DebianMaintainer#Granting_Permissions
[mentors]: https://mentors.debian.net/
[tracker]: https://tracker.debian.org/
[package overview]: https://qa.debian.org/developer.php
##Uploading
###Supported Distributions
The following distributions are supported for backports. Please don't use
unstable or stable as target distribution.
unstable or stable as target distribution. Append "~bpo${release}+${build}" to
the version number, e.g. "1.2-3" becomes "1.2-3~bpo9+1" (or use `dch --bpo`).
| Source Distribution | Backports Distribution |
|---------------------|----------------------------------------------|
| buster | stretch-backports |
###Basic Rules
With the release of a new stable version uploading packages with versions
greater than in new stable or new stable-security are not allowed. So if you
want to upload a new package version from e.g. bullseye to stretch, use
stretch-backports-sloppy as the target distribution.
* Make sure that you have a proper build environment that only contains the suite for which the backport is for (e.g. stretch if you want to upload to stretch-backports) and no unneeded backports. Maybe you want to consider pbuilder or cowbuilder for building packages.
* Append "~bpo${debian_release}+${build_int}" to the version number, e.g. "1.2.3-4" now becomes "1.2.3-4~bpo9+1", or for native packages, "1.2.3" becomes "1.2.3~bpo9+1".
* Please only upload package with a notable userbase. User request for the package may be an indicator.
* Don't backport minor version changes without any user visible changes or bugfixes
* To guarantee an upgrade path from stable+backports to the next stable, the
package should be in testing.. Of course there are some exceptions: Security
updates. If your package had a security update you can upload a new backport
even if its not yet in testing. If you have good reasons to update a package
which is already is in backports with a newer version from unstable (which is
intended for testing), come and speak to us. Common exceptions are: critical
bugs fixed, library transitions.
* Do not do any changes to the package beside of backporting stuff.
##Packaging
* Do not make any changes to the packaging unrelated to backporting. Keep the
diff between the testing and the backports versions as minimal as possible.
* Make sure that you have a proper build environment that only contains the
suite for which the backport is for and no unneeded backports. Maybe you want
to consider pbuilder or cowbuilder for building packages.
* Document all changes you needed to do in order to make it run on stable.
* Please submit your changes to the debian VCS-\* (or ask the maintainer to).
* It is recommended to include all changelog entries since the last version on
debian-backports or since stable if it's the first version. You should do
this by passing "-v<version>" to dpkg-buildpackage. Eg: "debuild -v0.7.5-2",
where "0.7.5-2" is the version in stable. If the package wasn't in stable or
backports before you don't have include the changelog entries (but you are
free to do so). It helps others to follow the changes introduced with the
backport (by reading the changes mailing list).
* Before uploading please think about how useful the package is for stable
users and if you want to support the package until support for the
distribution you uploaded ends. You should consider adding yourself to the
Uploaders field of the debian/control file or subscribing to the package
though PTS. What is important is that you track the package for the lifetime
of the release cycle (stable and oldstable).
* Backports of an updated version of a package that was backported before
*may* have a changelog that merges entries of backports of previous versions,
but this is **not required**.
* If the packages lists a VCS in the debian/control file, please ask the maintainer
of the package to add your changes there, or ask for permission to do it yourself.
If you feel you would need to diverge from these rules, either discuss it on the [mailing list](https://lists.debian.org/debian-backports/) or bring it up with the [Backports Team](mailto:backports-team@debian.org) for an exception.
###Uploads for old-stable backports
With the release of a new stable version uploading packages with versions greater than in new stable or
new stable-security are not allowed. If you want newer package versions in old-stable-backports we created a
new suite for that: oldstable-backports-sloppy. So if you want to upload a package from bullseye to stretch
use stretch-backports-sloppy as target distribution.
###Additionally
where "0.7.5-2" is the version in stable.
* Backports of an updated version of a package that was backported before *may*
have a changelog that merges entries of backports of previous versions, but
this is **not required**.
* Do not lower the standards version, it is just useless.
* Do not add lintian/linda overrides to suppress the 'wrong-distribution'
warnings.
* Do always look at the interdiff between the testing version and the backports
version, keep in mind that it should be as minimal as possible.
* Do write good changelogs and document all changes you needed to do in order
to make it run on stable.
* Do not add lintian overrides to suppress the 'wrong-distribution' warnings.
##Security Uploads
......@@ -124,31 +120,20 @@ ticket in the [backports queue] on the [RT].
Please follow the following template and provide us with the required
information to write a BSA. Please don't wait for the BSA and upload
immediatly.
immediately.
Subject: [BSA-XXX] Security Update for <packagename>
<Uploader> uploaded new packages for <packagename> which fixed the
following security problems:
CVE-XXXX or whatever ID if existant
short description
short description
...
CVE-....
CVE-....
....
For the stretch-backports distribution the problems have been fixed in
version <packageversion>.
<other distributions if any>
##Best Practice
###Check NEW queue
Check the [backports NEW queue] to avoid
double efforts before you start to backport something.
###Inform the Backporter
If there is already a backport of your package of choice but it's outdated and you want to update it please inform the person who backported the last accepted version about your intentions. You can get the information from <https://backports.debian.org/changes/stretch-backports.html>
<other distributions if any>