debian mentors/ guides/ Package Lifecycle

The Lifecycle of a Package

When a package is created for the Debian distribution there are certain stages it goes through. This guide attempts to outline these stages. It is aimed at those who are new to Package Maintenance, and tries to deal with the most common cases.

This oage attempts to deal with the lifecycle of a single package, you might also be interested in ?DebianLifecycle.


First the inital package is created. This involves creating a debian source package from the upstream tarball. This is covered in lots of other places (and hopefully a tutorial here soon). Probably the best place to go for information on this process is the new maintainers guide.

The package is then checked, and any necessary changes made.

Initial Upload

When the package is ready for the archive it is uploaded. Uploading appears to be a simple process, just using FTP to move the files to a specific machine, but there is lots of infrastructure behind the scenes to do all the work from there (perhaps it will be the subject of another guide).

The most important thing is that uploads are only accepted if they are signed by a DebianDeveloper. This means that if you are new to packaging then you cannot upload your own packages to Debian. If you wish to have them included in the distribution you will need a sposored upload.

A sponsored upload involves the developer who will sponsor you checking the package, and if they are happy with it rebuilding it and signing the result. They will then either upload the package themselves, or send it back to you so that you have the pleasure of doing it yourself.

When your new package is uploaded it will then be placed in what is known as then NEW queue (or simply NEW). This is a staging area where the package is not available for download by the users. It waits there until it is checked and approved by one of the ftp masters. They have final responsibility over what goes in to the archive, so they check that the license of the package is suitable for instance. If they accept the package you will receive an ACCEPTED mail. If there is something wrong you will receive a REJECTED mail with an explanation. You will then be able to correct the problem and re-upload.

Once the package has been ACCEPTED it will be moved in to the archive, and then will be pushed out to all the mirrors, and so be accessible to the users.

Bug reports

Once the package can be used you will probably start receiving bug reports for the package. You will need to diagnose the problem, and either come up with a fix, or work with the upstream authors to fix the problem. You can use the BugTrackingSystem to manage the bug report.

Transition to testing

Uploads are made to the Unstable distribution, and from there move to the Testing distribution when they are ready. Being ready means 3 things usually.

When all of these criteria are met ( can answer why they aren't), the package will migrate to testing, and you will receive an email.

New Versions

New versions of a package are uploaded for two reasons:

They work just like the original uploads, except that they probably wont have to go through NEW (and you will usually recieve the ACCEPTED mail quickly). If your package was uploaded through a sponsor it is usual for the same sponsor to upload the new version.


Sometimes a maintainer does not wish to continue maintaining the package. In these cases they will orphan it, or request an adopter. This can be a great way to get packages to maintain yourself. See wnpp for more information.


Removal happens when a package is no longer needed, or is deemed of too low quality for the distribtion. Then removal is requested using the BugTrackingSystem and someone will remove the package from unstable. The package will then automatically be removed from testing after a few days.

There is also a different sort of removal. If a ReleaseCritical bug report is left unfixed in a package in testing for more than a few days then it will be removed from the testing distribution, and only allowed back in when the release critical bug has been fixed.

(C) 2006 James Westby (James)