The Debian Life Cycle - Maintenance and Release of the Debian Distribution Packages
Debian Package Life Cycle
Every different Debian software package has a specific maintainer. This person keeps track of the different releases that are sent from the software authors, and then they ensure that the package is compliant with the Debian Policy. They have to make sure that the new package also coheres with the other areas of the distribution and still meets the Debian standards. The package maintainer also has to be in contact with the users and developers, since they use the bug tracking system to follow up on the reports and then fix the problems that they find. There is normally only one maintainer for a package, but there are starting to be many smaller teams who help to maintain the bigger packages to ensure better quality.
Sometimes, the maintainer will release a package by uploading it into the “incoming” directory for the Debian software package archive. This package archive is an “upload queue” which will batch transmit the packages into the incoming directory at set times. These uploads are then automatically processed to make sure that they are formed right, such as verifying that all of the requisite files are there, and then the package is signed by a Debian developer with OpenPGP-compatible software. Since all of the Debian developers have public keys, they are able to digitally sign these new releases. The developers sign the packages so that they are able to then reject any uploads from hostile sources outside the project and keep up accountability if there is a major problem with the package, a policy violation, or bad code.
When the software package is well-formed, valid, and signed, it is then installed into the archive and distributed to hundreds of mirrors around the world. At first, the package uploads that are accepted into the archive pool are only available as an “unstable” set of packages, but they still contain the newest version of the package. If the new code is an untried one, the packages are only distributed with disclaimers that are extremely clear to the user. For these packages to become candidates for the next major stable release, they have to get into the “testing” area first. Here are the requirements for a software package to find it’s way into the testing suits:
- It has to have been marked as unstable for a specific length of time.
- It cannot have a larger number of bugs filed against it than the version that is already out in testing (these are bugs that would make it unsuitable for release).
- It has to be ready for all of the different architectures that it claims to support.
- It has to be a package for one of the architectures that is set to release. Tthe package cannot be released if the architecture isn’t set to release yet, or if it has never been considered for testing.
- It cannot depend on other versions of packages that don’t meet any of the other conditions above.
Every now and then, the release manager will publish guidelines for the developers so that they can get the release ready in accordance with the different policies and help to make a better decision for the release. This is usually when all of the important software is up to date in the candidate for the release suite for all of the architecture types which it’s planned, and when all of the other goals that were set have been met. Then, the packages can become part of the released suite.
The next part of this series will take you through the branches of Debian releases as well as the official and unofficial repositories.
This post is part of the series: An In-Depth Review of Debian
For those Linux users who aren’t familiar with Debian, here is your BrightHub in-depth review to help you completely understand the system.